• Articolo

File desktopProtezione contro Conformità

Wes Miller

In qualità di professionisti dell'IT, vi sarete spesso trovati a dover raggiungere obiettivi che anziché di essere complementari tra di loro erano in conflitto. La protezione e la conformità sono due obiettivi organizzativi talmente correlati che il conseguimento di uno dovrebbe rafforzare l'altro, ma purtroppo non è sempre così. La mia intenzione con questo articolo è fornirvi

una panoramica sui motivi per cui "protetto" non sempre coincide con "conforme" alle iniziative richieste e viceversa o, per lo meno, non sempre conformità e protezione sono complementari come dovrebbero essere.

La protezione non è una casella di controllo

Risorse di SDL

La conformità generalmente implica dei requisiti (persone, processo, infrastruttura, tecnologia e così via) imposti su un'organizzazione, settore, azienda o prodotto dall'esterno. A volte la conformità ha a che fare con uno standard promulgato dall'interno del settore (come le normative Payment Card Industry Data Security Standards o PCI-DSS). Idealmente si tratta di iniziative in linea con il modo di lavorare della vostra organizzazione, al meno fino a un certo punto. Con il proliferare dell'adozione di uno standard, vi sarete resi conto che non è possibile ignorarlo, se si vuole avere successo nel campo degli affari. L'unico atteggiamento da seguire è quindi rispettarlo e trarne i massimi vantaggi.

È l'altro tipo di conformità ad essere di solito più problematico. Mi riferisco alle iniziative stabilite dal governo, come le normative Health Insurance Portability and Accountability Act (HIPAA) e Sarbanes-Oxley (SOX), in cui l'implementazione e la sincronizzazione raramente sono una questione di scelta.

Il punto principale da capire sulla conformità alle normative è che spesso implica un approccio dall'alto verso il basso. In genere un banalissimo modello definisce l'iniziativa ed è necessario esaminare i propri prodotti e processi per capire in che modo integrarli con l'insolito modello fornito. Occorre tenere presente non soltanto l'intento dell'iniziativa di conformità ma soprattutto le eventuali conseguenze legali o finanziarie in cui si potrebbe incorrere se non si seguisse il suddetto modello.

Sebbene l'intento di molte iniziative di conformità sia lodevole, l'implementazione è spesso difficile e non sempre porta al raggiungimento dell'obiettivo desiderato. E purtroppo molte di tali iniziative sono inefficaci, il che significa che il mancato raggiungimento dell'obiettivo di conformità non comporta conseguenze legali o finanziarie.

Come paziente, posso dirvi che non sono in grado di descrivere il reale vantaggio di HIPAA per me. L'unico aspetto che potrei sottolineare è che ho molte più scartoffie da compilare di quando andavo da uno specialista. E le conseguenze impreviste potrebbero essere anche peggiori. Avete mai provato a passare importanti informazioni mediche da un dottore o ente ad un altro? In assenza di autorizzazione scritta, questo processo non è possibile, indipendentemente dall'urgenza con cui si ha bisogno di tali informazioni.

Il punto è che, in molti sensi, alcune iniziative di conformità diventano procedure di compilazione dei campi. Il che significa che si progetta o modifica il proprio processo o prodotto esclusivamente per soddisfare l'iniziativa di conformità. Come spesso chiedo a mio figlio di tre anni: "è una buona idea?"

La protezione, d'altra parte, è un'iniziativa svolta dal basso verso l'alto, quando viene eseguita correttamente. Indipendentemente dal fatto che si stia progettando un prodotto software o l'architettura per la nuova rete della propria organizzazione, il concetto principale da ricordare è "valutare due volte, eliminare una volta sola". Quando si progetta l'architettura di un prodotto, ad esempio, all'inizio è consigliabile descrivere la comunicazione, la localizzazione, le versioni e così via, ossia la procedura preliminare dovrebbe descrivere gli elementi di protezione che è necessario creare nell'applicazione dal primo giorno e che si dovrebbe continuare ad esaminare e perfezionare in ogni fase dello sviluppo.

Se ci si trova a dover gestire un'applicazione o un'architettura ereditata da altri, come avviene nella maggior parte dei casi, è essenziale eseguire il tipo di analisi della protezione approfondita che cito spesso in questo articolo. Se non si capisce il funzionamento di un elemento, come si può capire qual è il suo grado di protezione? Per ulteriori informazioni su Microsoft® Security Development Lifecycle (SDL), consultate il riquadro "Risorse SDL".

Il quadro generale

Ricordo di avere imparato fin da subito che la protezione non equivale alla semplice implementazione della codifica, degli elenchi di controllo accessi (ACL) o dell'infrastruttura a chiave pubblica (PKI). La protezione reale consiste nel comprendere appieno il quadro generale: Capire perché quella versione di quel protocollo è stata eliminata o non è mai stata supportata; perché questa nuova parte della struttura blocca gli attacchi MITM (man-in-the-middle); come mai la propria implementazione per il prodotto v2 è molto più sicura rispetto alla v1, anche se la v1 era molto più rapida. Ed è inoltre necessario comprendere in che modo le varie parti della propria infrastruttura vengono combinate insieme.

La conformità, dall'altro lato, comporta l'utilizzo della propria tecnologia e la verifica del soddisfacimento di determinati criteri all'interno dell'infrastruttura creata. Alcune iniziative, tra cui Payment Card Industry Data Security Standards (PCI-DSS) o North American Electric Reliability Council (NERC), sono ben concepite e potrebbero finire con l'incoraggiare un vero e proprio cambiamento in termini di protezione. Ma, tutto sommato, con una selezione così vasta di iniziative di conformità che è necessario conciliare con i propri specifici progetti e le risorse finite disponibili, le iniziative di protezione perdono terreno.

La protezione è da lungo tempo la "figliastra" dello sviluppo software. Certamente molti di voi hanno lavorato in un'organizzazione in cui la protezione era qualcosa di cui occuparsi in un secondo momento. E, dunque, le iniziative di conformità sono state create proprio perché la filosofia "la protezione può attendere" non funziona e non ha mai funzionato.

La filosofia del "minimo indispensabile"

Recentemente ho cambiato lavoro. Ora lavoro per una nuova azienda qui ad Austin, Texas, che sta creando una tecnologia di whitelist delle applicazioni piuttosto simile alla tecnologia che abbiamo creato a Winternals con il nostro prodotto Protection Manager. Un aspetto che mi è sembrato molto interessante da affrontare con i clienti è la loro valutazione del grado di protezione attuale delle tecnologie correnti in uso o, in modo più specifico, la loro percezione del grado di protezione fornito dalla loro infrastruttura nella suite di tecnologie in uso. Sebbene sia probabile che la maggior parte di loro siano protetti e non soggetti a problemi di violazione della protezione, l'affermazione che sento spesso e che mi fa raccapricciare è che un sistema è "abbastanza sicuro".

Le iniziative di conformità sono buffe: è possibile portarle a compimento o non riuscire a completarle affatto. La responsabilità è vostra. La conseguenza del mancato compimento di un'iniziativa è di solito una multa, una penale o il licenziamento da un'organizzazione. Spesso tali conseguenze non garantiscono che le cose cambino realmente.

Nel caso di un'iniziativa governativa, incontro regolarmente l'atteggiamento "abbastanza buono per soddisfare il revisore" o la volontà di eseguire un sistema senza attuare alcun framework di conformità vero e proprio a causa di un sovvenzionamento inadeguato della normativa legislativa di supporto (come la HIPAA). È molto più conveniente guidare senza assicurazione e affrontare le eventuali conseguenze in un secondo momento!

La protezione colpisce spesso lo stesso blocco stradale, ma nella mia mente almeno è più concreta. Se voi, in qualità di sviluppatori o implementatori, riusciste a far capire ai responsabili che un mancato rispetto delle specifiche renderebbe il prodotto molto più vulnerabile agli attacchi, una volta lanciato il prodotto o completata la distribuzione, avrete la coscienza pulita per avere svolto il vostro compito. Nel campo delle iniziative di conformità, la mia esperienza mi insegna che spesso il soddisfacimento di una specifica è un processo affrettato, condotto con un budget estremamente limitato. Secondo la mia opinione, l'obiettivo è soddisfare il livello minimo richiesto dall'iniziativa, senza capirne lo spirito vero e proprio.

Il vostro ruolo

Risorse di protezione e conformità

Sebbene possa essere idealistico da parte mia sostenere che dovreste rendere il vostro prodotto e la vostra organizzazione il più possibile sicuri, la realtà è che la maggior parte delle iniziative di conformità non sono altro che un compromesso derivante da una scarsa progettazione o, più spesso, soddisfazione. Viviamo in un mondo dove vige la filosofia dell'accontentarsi. Ma, nel settore della protezione, raramente ci si può accontentare. In qualità di professionisti IT, noi potremmo prendere a cuore le iniziative di conformità e tentare di portarle a compimento sia nell'essenza che nell'implementazione, verificando che l'infrastruttura che stiamo creando non sia soltanto protetta come potrebbe essere, ma piuttosto come dovrebbe essere. In altre parole, dovremmo garantire una conformità tramite protezione reale e non soltanto rispettando l'iniziativa.

È importante fare un passo indietro ed esaminare la tecnologia che si sta creando, sia nel caso in cui si tratti di una parte di software commerciale che nel caso in cui sia una serie di tecnologie da integrare in un sistema di proporzioni maggiori. Non sottolineerò mai abbastanza l'importanza di avere una visione chiara delle componenti del sistema, del loro funzionamento congiunto e delle minacce principali a cui tale sistema potrebbe essere sottoposto.

In base al settore in cui operate, differenti iniziative di conformità potrebbero giocare un ruolo importante nel vostro lavoro. Potreste incontrarle nella vostra vita quotidiana o soltanto in caso di progettazione di nuovi progetti o tecnologie. Oppure, tali iniziative potrebbero far parte del vostro lavoro durante verifiche o analisi di conformità appositamente concepite. Non importa. Ritengo che tali iniziative non vadano ignorate, ma mi piacerebbe che voi sfidaste lo status quo e, invece di operare esclusivamente per il soddisfacimento delle suddette iniziative, eseguiste un'analisi completa della protezione per capire la vostra tecnologia dall'interno e la modellaste contemporaneamente in base all'analisi della conformità.

Cosa avete da perdere?

Tutto sommato, le penali dovute al mancato soddisfacimento di un'iniziativa di conformità potrebbero apparire ambigue. La mancanza di conformità vi mette al rischio proprio per lo scenario da cui l'iniziativa dovrebbe proteggere. Le conseguenze potrebbero sembrare vaghe o remote, ma sono reali. Tuttavia, non è detto che influiscano direttamente su di voi. Siate intransigenti, ma prendete sempre a cuore le tipologie di scenari peggiori.

Se si osserva lo stesso spazio da una prospettiva rigorosa di protezione, la minaccia dovrebbe essere ovvia e soprattutto dovreste essere in grado di identificare immediatamente i potenziali rischi di vulnerabilità.

Molte persone con cui ho discusso questo argomento hanno evidenziato il fatto che le iniziative di conformità sono talvolta dissimulate, poiché spesso danno adito ad un'interpretazione aperta. Una volta condotta un'analisi della protezione, tuttavia, la stessa regola non vale più per le omissioni di protezione. Le minacce immediate dovute ad una protezione ignorata dovrebbero essere chiaramente visibili. Se non lo sono, dovreste riconsiderare la scelta di coloro che si occupano delle analisi della protezione; potrebbero mancare dei membri importanti nel vostro team, in grado di individuare i veri problemi nella vostra soluzione.

Un cane che si morde la coda

Nell'articolo dello scorso anno relativo alla protezione, ho parlato di "Come evitare di perdere i dati" (technet.microsoft.com/magazine/cc162325). Un anno è passato, altri sistemi sono stati compromessi, altri computer portatili sono andati persi e altre informazioni personali sono cadute in mani potenzialmente discutibili. Non è facile dire se siano stati compiuti dei progressi. Perché siamo ancora allo stesso punto? I progetti spesso vengono eseguiti in ritardo, con budget limitato e risorse sovraccariche, nel tentativo di fornire un numero eccessivo di elementi in un intervallo temporale estremamente ridotto.

Questo tipo di ambiente, purtroppo, ne genera un altro in cui il minimo indispensabile diventa la norma. Non è certamente questo il modo per garantire che una soluzione sia protetta o conforme e, contemporaneamente, non influisca su costi o scadenze di un progetto.

Personalmente, sono un fermo sostenitore delle seguenti idee:

  1. Non si dovrebbe creare una soluzione se non si è disposti a proteggerla.
  2. Ogni qualvolta si aggiungono nuovi elementi, è necessario progettarne la protezione prima di iniziare.
  3. Se la vostra organizzazione non è disposta a investire nella protezione all'interno del processo di progettazione, dovreste interrogarvi sugli obiettivi organizzativi o generali della vostra azienda.

Le organizzazioni dispongono sempre più spesso di dati personali di partner e clienti e hanno la responsabilità di tenere tali informazioni al sicuro. Purtroppo viviamo in un mondo in cui, troppo spesso, la protezione non è la norma e i dipendenti non si sentono sicuri quando vengono interpellati sull'impegno dell'organizzazione nei confronti della protezione.

La mancanza di protezione (non di conformità) molto spesso è sintomo del fatto che affermazioni quali "è ora di proteggere il sistema" e concetti quali "assicurazione contro il furto di identità" sono diventati uno stratagemma standard di responsabilità per placare l'ira di clienti, studenti, pazienti e dipendenti i cui dati personali (e il potenziale benessere finanziario) sono stati compromessi.

A tutti noi viene chiesto di fare più del dovuto, spesso con compensi inadeguati e scadenze molto brevi. Ma è nostra responsabilità, in qualità di professionisti dell'IT, interrogarsi sui motivi per cui la protezione non sia il centro d'interesse principale e sul perché i responsabili troppo spesso pensino alla protezione soltanto quando si trovano di fronte ad iniziative di conformità o in caso di violazioni della protezione e delle relative minacce legali reali o potenziali (che potrebbero imbarazzare e mettere a rischio l'organizzazione).

La mia sfida

Vi invito a sfidare lo status quo. Se vi viene richiesto soltanto di soddisfare gli obiettivi di conformità, provate a non sprecare tempo nel soddisfare il concetto di protezione di qualcun altro. Siate certi, piuttosto, che il vostro obiettivo sia la protezione del sistema e, durante il processo, la definizione di elementi sufficienti nel processo o nella vostra infrastruttura per portare a compimento l'iniziativa di conformità. Per ulteriori informazioni su questo argomento, consultate il riquadro "Risorse di protezione e conformità".

In sintesi, ricordate che la conformità troppo spesso non è un percorso verso la protezione. La protezione, tuttavia, se implementata e applicata correttamente, spesso può essere un percorso verso la conformità.

Wes Miller è un Senior Technical Product Manager di CoreTrace (www.CoreTrace.com) di Austin, Texas. In passato ha lavorato per Winternals Software e per Microsoft in qualità di Program Manager. È possibile contattarlo all'indirizzo technet@getwired.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.