Introduzione
La "sicurezza" in generale viene percepita come una disciplina complessa. Un "modello" è un termine di cui la
maggior parte delle persone crede di avere una comprensione intuitiva, poiché è una parte naturale dell'educazione
umana riconoscere e generalizzare sui modelli percepiti. Per gli scopi di questo esercizio prenderemo le seguenti
definizioni come quelle funzionanti:
Sicurezza è "La condizione di un sistema che risulta dallo stabilimento e la manutenzione
delle misure per proteggere il sistema." [1]
"Un modello è l'astrazione da una forma concreta che continua a ricorrere in contesti non
arbitrari specifici." [2]
Quindi, per provare a raggruppare i due termini, la "sicurezza" e i "modelli" possono introdurre alcune tensioni.
Ci sono stati diversi tentativi per produrre i modelli di sicurezza (vedere appendice A). Questo
documento ha tentato di raccogliere e codificare il materiale raccolto in diversi anni da diversi praticanti da diversi
contatti con i clienti producendo una figura di responsabile per i modelli di sicurezza IBM. La definizione funzionante
per i "modelli di sicurezza" nel contesto di questo documento è:
Un'astrazione delle condizioni che risultano dallo stabilimento e la manutenzione delle misure ricorrenti
utilizzate per proteggere il sistema.
Nella comunità di sviluppo del software c'è al momento uno sforzo per stabilire [3] una metodologia per lo sviluppo del modello.
Fondamentale per qualsiasi scienza o disciplina è un vocabolario comune per esprimere i concetti ed un
linguaggio per relazionarli insieme. L'obiettivo dei modelli nella comunità del software è di creare un corpo di
letteratura per aiutare agli sviluppatori software a risolvere i problemi ricorrenti rilevati in tutto lo sviluppo
software. I modelli aiutano a creare un linguaggio condiviso per comunicare le intuizioni e le esperienze relative
a questi problemi e alle loro soluzioni. Formalmente codificando queste soluzioni e i loro rapporti è possibile
riportarecorrettamente il corpo della conoscenza che definisce la nostra comprensione delle buone architetture che
rispettano le necessità dei loro utenti. La creazione di un linguaggio comune dei modelli per trasmettere le
strutture ed i meccanismi delle architetture consente di ragionare in modo intelligibile. L'attenzione principale
non è sulla tecnologia ma piuttosto sulla creazione di una cultura per documentare e supportare l'architettura di
progettazione del suono. [4]
Il punto fondamentale di confusione è che i modelli, come la bellezza, sembrano essere negli occhi di chi guarda.
In questo modo, se si dispone di 5 persone addette alla sicurezza, queste definiranno i modelli specifici
dell'area di interesse.
È per questo motivo che si sta continuando a discutere di "ruoli" per aiutare a raggruppare i modelli per comunità di
interesse.
Chi è il primo?
Nel mondo del software, ci sono persone che progettano le cose, persone che disegnano e scrivono documenti, persone che
scrivono codici e persone che mettono tutti i pezzi insieme e forniscono i sistemi basati sul computer.
Ogni organizzazione probabilmente ha il proprio modo di definire le attività, ma ci sono ruoli archetipici.
Un'architettura è un modello idealizzato di una persona, un oggetto o un concetto dal quale sono derivate,
copiate, modellate o emulate simili istanze. In psicologia, un archetipo è un modello di una persona, personalità o
funzionamento. [5]
Nelle medie e grandi imprese, le attività vengono assegnate a diverse persone in base alle loro responsabilità
organizzative. In generale, l'analista e le applicazioni di business devono proteggere gli asset di informazione
del business. Questi guidano la creazione dei requisiti di applicazione del business per la sicurezza.
Archetipo 1 - Analista del business
Nelle organizzazione che devono soddisfare i requisiti legislativi o regolatori, c'è a volte un insieme specifico di
attività al livello "C" per controllare e rafforzare queste norme. CSO e CPO in genere funzionano con gli
analisti di business per compilare un insieme di linee guida e requisiti corporativi - i fondamenti di una buona
pratica del business.
Archetipo 2 - Capo responsabile sicurezza (Riservatezza)
Molte organizzazioni di qualsiasi dimensione oggi hanno un firewall. Anche gli utenti singoli a casa stabiliscono dei
firewall per le loro reti domestiche. Qualcuno deve impostare ed eseguire la manutenzione dei dispositivi. Alcuni sono
semplici, altri complessi.
Archetipo 3 - Responsabile sicurezza rete
Quando si capiscono e si selezionano alcuni tipi di meccanismi di sicurezza per rispondere ai requisiti
specificati dal business, ci sono molte persone che lavorano insieme per implementare la sicurezza.
Archetipo 4 - Architetto della sicurezza
Sviluppatore della sicurezza, Distributore della sicurezza, Autore della politica della sicurezza, Amministratore della
politica di sicurezza, Amministratore del sistema della sicurezza
Ricerca dei modelli per Ruolo
Lo scopo di questo documento e della serie di slide che lo accompagna è di fornire un capo responsabile per
l'identificazione e l'illustrazione dei modelli di sicurezza comuni esistenti nella comunità di analisti del business
dei clienti IBM. L'attività del lavoro dei modelli di e-business è la riconciliazione del volume di
informazioni in un'astrazione abbastanza generale da essere afferrata dai professionisti che non si occupano della
sicurezza e che tuttavia mantengono abbastanza contesto da fornire un sostegno alla comunità che si occupa di
sicurezza.
IBM è microcosmo del più ampio settore software poiché rappresenta lo sviluppo del prodotto e lo sviluppo del servizio
di applicazione business, e inoltre i prodotti middleware per la gestione e la distribuzione delle applicazioni.
Ci sono molte metodologie per la progettazione e lo sviluppo delle applicazioni sicure (ad esempio, MASS, Open Group,
JAAS) ma molte di queste sono destinate ai professionisti qualificati in materia di sicurezza con una conoscenza
dettagliata della tecnologia. In questo modo, un gruppo di modelli sarà "modelli strutturali della sicurezza". Le
architetture dettagliate per la sicurezza sono necessarie per sviluppare la tecnologia e fornire soluzioni di sicurezza
e i modelli fanno riferimento a queste quando è necessario ma non è nostra intenzione documentare tutti i modelli
strutturali di sicurezza.
Informazioni sulla sicurezza
IETF è un'organizzazione che è stata fondamentale per lo sviluppo di Internet così come lo conosciamo oggi. IETF ha
stabilito un glossario relativo alla sicurezza nel 2000, e questo raggruppa la maggior parte dei concetti fondamentali
relativi alla sicurezza del computer. Sono stati fatti dei miglioramenti, nuove tecnologie e meccanismi vengono
inseriti ed eliminati poiché non più utilizzati, ma le definizioni di base restano inalterate.
La maggior parte dei componenti che sono in pratica oggi per la sicurezza includono quanto segue: identificazione
e autenticazione, autorizzazione, assicurazione, controllo, sicurezza del messaggio, riservatezza,
integrità. Piuttosto che fornire solo i modelli per ogni meccanismo di sicurezza singolo, questo capo responsabile
ha cercato nei meccanismi di sicurezza singoli per identificare le caratteristiche comuni. Questo white paper si
incentra sull'identificazione di un "modello di soluzione sicurezza". Questi elementi comuni derivano dalla
ricerca di un insieme dettagliato di elementi del modello singoli per ogni meccanismo di sicurezza (ad esempio,
l'autenticazione ---- nome utente, password, Kerberos, PKI) e quindi dall'astrazione di queste cose in comune
nell'autenticazione, l'autorizzazione, l'assicurazione ecc...
La ricerca degli elementi comuni in tutti i modelli di sicurezza è risultata nell'identificazione di 3 elementi
del modello secondario che sono presenti in determinate forme in tutti i tipi di soluzione di sicurezza:
-
è necessario che ci sia un punto nel software in cui viene chiamato il meccanismo di sicurezza (ad
esempio un "punto di controllo")
-
In generale ci sono alcuni tipi di meta-informazioni importanti per l'esecuzione di #1 e queste vengono
chiamate "sicurezza del sistema e proprietà di accesso"
-
esistono alcune attività relative all'inizializzazione e alla manutenzione in corso del meccanismo di sicurezza e
queste sono chiamate "gestione sicurezza/attività del flusso di lavoro".
Per dimostrare come ogni meccanismo di sicurezza singolo può essere associato a questi 3 elementi secondari, viene di
seguito riportato un esempio di "identificazione". Ancora, dal glossario IETF:
identificazione - (I) Un atto o un processo che presenta un identificatore di un sistema in modo
che il sistema possa riorganizzare un'entità del sistema e distinguerla da altre entità. (Vedere:
autenticazione.)
La distinzione di una persona da un'altra quando si richiama un'applicazione è un modello che ogni azienda confronta.
Le strategie per indirizzare il problema aziendale varia in base al numero e alla diversità degli elementi coinvolti
nell'applicazione e al modello di sviluppo. Alcune aziende lasciano la decisione relativa alla "denominazione"
alle applicazioni singole o forse ad un gruppo di applicazioni in una linea aziendale. Alcune aziende sono
limitate dal software nei centri dati. Alcune hanno accoppiato fortemente l'ambiente di distribuzione dell'applicazione
ad un insieme di meccanismi.
Tuttavia, esiste un punto nel quale l'"identificatore" viene presentato ad un'applicazione e questo viene considerato
come un modello del "punto di controllo della sicurezza", per l'identificazione. La quantità ed il tipo di
informazioni richieste varia anche in modo significativo. Un identificativo può essere il vero nome di una
persona, (ad esempio Maryann Hondo)o uno pseudonimo (ad esempio mhondo). L'identificativo può essere
globalmente univoco (un UUID) o può essere unico in uno spazio nome qualificato (ad esempio mhondo@us.ibm.com) .
Caratteristiche di un modello di sicurezza
-
Definizione di uno o più punti di controllo (Identità, autenticazione, autorizzazione, applicazione della politica,
controllo, conformità, sicurezza del messaggio)
-
Definizione delle proprietà di sicurezza del sistema (Limiti di configurazione; regole di sicurezza e accesso)
-
Definizione delle attività di gestione Predisposizione, sincronizzazione del registro/repository, gestione,
controllo)
-
RFC 2828 Glossario sicurezza Internet Maggio 2000
-
Conoscenza e utilizzo dei modelli nello sviluppo software, Dirk Riehle e Heinz Zullighoven.
-
Modelli di progettazione: gli elementi del software orientato all'oggetto riutilizzabile, Erich Gamma,
Richard Helm, Ralph Johnson, e John Vlissides.
-
Modelli e software: Concetti essenziali e terminologia, Brad Appleton: http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html#Origins
-
Wikipedia: http://en.wikipedia.org/wiki/Archetype
|