Sicurezza dei sistemi informatici Master di I livello

Sicurezza dei sistemi informatici Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione Seconda lezione 27/4/2007

Contenuto della lezione n n n Politiche per l’integrità Politiche ibride Autenticazione

Politiche per l’integrità n n Requisiti di Lipner Modelli di Biba Matrice di Lipner Cenni al modello di Clark-Wilson

I requisiti di integrità di Lipner 1. 2. 3. 4. 5. Gli utenti non devono scrivere programmi ma usare solo programmi e database di produzione I programmatori sviluppano e testano di programmi non sui sistemi di produzione, se hanno bisogno di usare dati veri, riceveranno dati di produzione filtrati attraverso un processo speciale e useranno solo quelli Un processo speciale deve essere eseguito per installare un programma dal sistema di sviluppo a quello di produzione. Il processo speciale del requisito 3 deve essere controllato e sottoposto ad audit. Gli amministratori devono accedere allo stato del sistema e ai log generati

Modelli per l’integrità n I requisiti suggeriscono i seguenti principi n n n Separazione dei compiti. Se due o più passi sono richiesti per compiere una funzione critica, devono essere impiegati almeno due soggetti differenti. Muovere un’applicazione dal sistema di sviluppo a quello della produzione è un esempio di funzione critica. Separazione delle funzioni. Funzioni differenti devono usare dati differenti. Per esempio, gli sviluppatori non devono sviluppare nuovi programmi nell’ambiente di produzione e non possono processare dati di produzione nell’ambiente di sviluppo. Si può dar loro dati “sanitized”. Auditing. E’ il processo di analisi del sistema per determinare quali azioni sono state compiute e da chi

Modelli per l’integrità n Modello di Biba n n n insieme di soggetti S insieme di oggetti O insieme di livelli di integrità I relazione di ordine <= su I i(s) rappresenta il livello di integrità di s, per un programma indica quanto è corretta la sua esecuzione i(o) rappresenta il livello di integrità di o, indica quanto è affidabile il contenuto

Modello Low-Water-Mark di Biba n n n s può scrivere o se e solo se i(o)<=i(s): un soggetto non può scrivere qualcosa di più affidabile se s legge o, allora i(s) diventa pari a min{i(s), i(o)}: l’integrità del soggetto si può “contaminare” s può eseguire s’ se e solo se i(s’)<=i(s): non si può eseguire qualcosa di più affidabile

Modello di Biba di integrità stretta n n n s può leggere o se e solo se i(s)<=i(o) s può scrivere o se e solo se i(o)<=i(s) s può eseguire s’ se e solo se i(s’)<=i(s) E’ il duale di Bell-La Padula Vale il seguente teorema: in un trasferimento di informazioni o 0 → s 1 → o 1 → s 2 → o 2 →. . → sn → on l’integrità dell’oggetto finale è minore o uguale di quello di partenza

LOCUS e Biba n n Scopo: prevenire che un programma non fidati alteri dati o altri programmi Approccio: usare livelli di fiducia n n un livello di credibilità basato sulla stima di affidabilità del programma (0 non fidato, n altamente fidato) I trusted file systems contengono programmi con un solo livello di credibilità Un programma può essere eseguito solo se ha credibilità maggiore del processo che lo lancia Si deve usare il comando run-untrusted per eseguire un programma con minor livello di credibilità

Matrice di integrità di Lipner n n Lipner è riuscito a coniugare Bell-La Padula (confidenzialità) e Biba (integrità) Un soggetto s può leggere un oggetto o se n n n s ha un livello di sicurezza maggiore o uguale a quello di o o ha un livello di integrità maggiore o uguale a quello di s In modo inverso per la scrittura

Livelli/categorie di integrità n Tre livelli di integrità: n n ISP(System Program): per programmi di sistema IO (Operazioneal): programmi di produzione, tool di sviluppo ISL (System Low): per tutti gli utenti Due categorie di integrità n n ID (Development): entità in sviluppo IP (Produczione): entità di produzione

Livelli/categorie di sicurezza n Due Livelli di sicurezza n n n AM (Audit Manager): system audit, funzioni di amministrazione SL (System Low): ogni processo può leggere tali dati Tre Categorie di sicurezza n n n SP (Production): codice e dati di produzione SD (Development): programmi per la produzione in sviluppo ma non in uso SSD (System Development): programmi di sistema in sviluppo ma non in uso

Livelli di sicurezza degli utenti Soggetti Livelli di sicurezza Livelli di integrità Ordinary users (SL, { SP }) (ISL, { IP }) Applicaction developers (SL, { SD }) (ISL, { ID }) System programmers (SL, { SSD }) (ISL, { ID }) System managers and (AM, { SP, SD, SSD }) auditors (ISL, { IP, ID}) System controllers (SL, { SP, SD }) and downgrade privilege (ISP, { IP, ID}) Repair (SL, { SP }) (ISL, { IP })

Livello di sicurezza degli oggetti Oggetti Livelli di sicurezza Livelli di integrità Development code/test data (SL, { SD }) (ISL, { IP} ) Production code (SL, { SP }) (IO, { IP }) Production data (SL, { SP }) (ISL, { IP }) Software tools (SL, ) (IO, { ID }) System programs (SL, ) (ISP, { IP, ID }) System programs in modification (SL, { SSD }) (ISL, { ID }) System and application logs (AM, { appropriate }) (ISL, ) Repair (SL, {SP}) (ISL, { IP })

Utenti ordinari n Un utente ordinario ha i livelli: n n n sicurezza (SL, { SP }) integrità (ISL, { IP }) Quindi può svolgere le seguenti operazioni n n n Leggere e scrivere dati di produzione : stessi livelli di sicurezza e integrità Leggere codice di produzione: stessa classificazione e (IO, {IP}) dom (ISL, {IP}) System program (SL, {SP}) dom (SL, {}) & (ISP, {IP, ID}) dom {ISL, {IP}) Repair oggetti (stessi livelli) Scrivere (ma non leggere) i log di sistema e di applicazione (AM, {SP}) dom (SL, {SP}) & (ISL, {IP}) dom {ISL, {})

I cinque requisiti n n E’ facile verificare che i cinque requisiti di Lipner sono soddisfatti Ad esempio un utente non può scrivere un programma perchè creerebbe un oggetto con un livello di integrità maggiore del proprio

Modello di Integrità di Clark-Wilson n Adatto all’integrità dei database L’integrità definita mediante vincoli che i dati devono rispettare Esempio: in una banca n n D depositi odierni, W prelievi odierni, YB bilancio di ieri, TB bilancio di oggi Vincolo di integrità: D + YB –W=TB Le transazioni ben formate portano uno stato consistente ad uno stato consistente Chi certifica che i vincoli siano sempre rispettati ?

Entità n n CDI: entità/dati soggetti a vincoli di integrità UDI: entità/dati non soggetti a vincoli di integrità IVP: procedure che controllano i vincoli di integrità TP: procedure di trasformazione, che portano il sistema da uno stato valido ad un altro stato valido

Regole di certificazione CR 1 Se un IVP è eseguito, deve assicurarsi che tutti i CDI siano in uno stato valido CR 2 Una TP deve trasformare un insieme di CDI da uno stato valido ad uno stato valido n n n CR 2 definisce come certificata una relazione che associa un insieme di CDI ad una TP CR 2 implica che una TP può corrompere un CDI se non è certificata per lavorare con quel CDI TP “balance”, CDI conti correnti. Sia C una relazione certificata, allora (balance, account 1), (balance, account 2), …. , (balance, accountn) C

Regole di rinforzo n n n CR 2 implica che una TP può corrompere un CDI se non è certificato a lavorarvi Esempio: La TP che investe denaro nel portafoglio azionario della banca corromperebbe i bilanci anche se la TP fosse certificata a lavorare sul portafoglio, perchè le azioni della TP potrebbero non avere senso sui conti bancari Da ciò nasce la prima regola di rinforzo

Regole di rinforzo ER 1 Il sistema deve garantire che solo le TP certificate ad operare su determinati CDI svolgano operazioni su di essi. ER 2 Il sistema associare a ciascun TP e insieme di CDI un utente. Il TP può accedere a quei CDI per conto dell’utente, ma non può accedere per conto di utenti non autorizzati. n n Il sistema deve mantenere le relazioni certificate Il sistema deve restringere l’accesso degli utenti alle TP mediante una relazione di permesso A, che specifica quali utenti possono eseguire quali TP su quali CDI

Utenti e regole CR 3 Le relazioni di permesso devono essere basate sulla separazione dei compiti. ER 3 Il sistema deve autenticare ogni utente che vuole utilizzare una TP

Uso dei Log CR 4 Tutte le TP devono scrivere in CDI di solo accodamento (append) tutte le informazioni sufficienti a ricostruire le operazioni svolte. n n Questo CDI è il log Gli amministratori devono essere in grado di capire cosa ha fatto una determinata transazione

Trattamento di Input non fidato CR 5 Ogni TP che prende in input un UDI può eseguire solo transformazioni valide, oppure nessuna transformazione, per ogni possibile valore dell’UDI. La trasformazione può quindi rifiutare il UDI o trasformarlo in un CDI. n In una banca, i numeri inseriti da tastiera sono UDI, che non possono essere dati in input ad una TP. Un’apposita TP deve validare tali numeri (rendendoli un CDI) prima di usarli; se la validazione fallisce, la TP rigetta il UDI

Separazione dei compiti ER 4 Solo il certificatore di un TP può cambiare la lista di entità associate al TP. Nessun certificatore di un TP, o di un entità associata al TP, potranno mai farlo.

I cinque requisiti Anche in questo caso è relativamente semplice far vedere che i cinque requisiti di Lipner sono soddisfatti

Politiche ibride n n n Molte organizzazioni hanno bisogno di politiche di rinforzo sia per la confidenzialità, che per l’integrità Modello della Chinese Wall Cenni al modello della Clinical Information Systems Modello ORGCON Modelli RBAC e TRBAC

Politica della Chinese Wall Introdotto da Brewer and Nash nel 1989 Il motivo per questo lavoro è stato quello di evitare che informazioni sensibili concernenti una compagnia siano passate a compagnie rivali per mezzo di consulenti finanziari n Si stabiliscono dinamicamente i diritti di accesso di utente in base a quello a cui l’utente ha già avuto accesso

Concetti della Chinese Wall n n Soggetti: Entità attive che accedono a oggetti protetti Oggetti: Informazioni legate ad una compagnia Dataset: insieme di informazioni di una data compagnia Classe di Conflict-of-Interest (Co. I): compagnie rivali di una data compagnia

Definizioni n n n Indicheremo con CD(O) il dataset a cui appartiene l’informazione O Indicheremo con COI(O) la classe di conflitto di interesse a cui appartiene l’informazione O Assumiamo che ciascun oggetto appartenga ad un unico dataset e ad un’unica classe COI

Classificazione dei dati Insieme di tutti gli oggetti Co. I 2 Co. I 1 Bank A Info Bank B Info Co. I 3 Gas A Oil A Info Oil B Info

Evoluzione dei diritti n Se un consulente legge un oggetto appartenente ad un CD in una data COI, non può più leggere oggetti di altri CD in quella COI n n E’ possibile che le informazioni apprese prima possano consentirgli di prendere decisioni “migliori” dopo (ovviamente in modo sleale) Indichiamo con PR(S) l’insieme degli oggetti che S ha già letto

Condizione di semplice sicurezza delle CW n Un soggetto s può leggere un oggetto o se e solo se: 1. 2. n n Esiste un oggetto o a cui s ha avuto accesso e CD(o ) = CD(o), oppure Per ogni o O, o PR(s) COI(o ) ≠ COI(o) Ignoriamo per ora i dati “sanitized” Inizialmente, PR(s) = , quindi qualunque cosa può essere letta all’inizio

In altri termini Un soggetto può leggere un oggetto se: n l’oggetto è in un dataset di cui il soggetto ha già letto qualcosa oppure n l’oggetto appartiene a una COI di cui il soggetto non ha letto ancora niente R R Gas A Consulltant Consu tant Bank A R X R R Oil B Bank B

Regola di lettura = John Insieme di tutti gli oggetti Co. I 2 COI 1 Co. I 1 Bank A Info Bank B Info COI 3 Co. I 3 Gas A Oil A Info Oil B Info

Confronto con Bell-La. Padula n n La politica Chinese Wall è una combinazione di libera scelta e di controllo obbligatorio (mandatory) Inizialmente un soggetto è libero di accedere a ciò che vuole Una volta fatta la scelta, per quell’utente è creata una Muraglia Cinese attorno al dataset a cui l’oggetto appartiene Si noti che la Chinese Wall può essere combinata con le politiche DAC

Scrittura n n Anthony e Susan lavorano per la stessa azienda di consulenza Anthony può leggere i CD di Bank A e di Gas A Susan può leggere i CD di Bank B e di Gas A Se Anthony potesse scrivere sul CD di Gas A, Susan potrebbe leggerlo n n Perciò, indirettamente, potrebbe acquisire informazioni su Bank B, un chiaro conflitto di interesse La regola per la lettura non è in grado di prevenire “fughe di notizie”

Proprietà * delle CW n Un soggetto s può scrivere un oggetto o se e solo se entrambe le condizioni valgono 1. 2. n La condizione di sicurezza semplice consente a s di leggere o Per ogni oggetto non “sanitized” o , se s può leggere o , allora CD(o ) = CD(o) In pratica s può scrivere un oggetto se tutti gli oggetti (non “sanitized”) che può leggere sono nello stesso dataset

In altri termini Un soggetto può scrivere un oggetto se n lo può anche leggere E n non può leggere dati di altre compagnie Bank B Bank A W X R Consultant A Consultant B R X W Oil B

Conclusioni e critiche Perciò secondo questa regola: Il flusso di informazioni è confinato all’interno della compagnia Però un utente che ha letto da più dataset non può scrivere nessuno oggetto n Inoltre, una volta che ha scritto in un dataset, può scrivere solo lì n

Regola di scrittura = John COI 1 Co. I 1 Bank A ABC Info Insieme di tutti gli oggetti Co. I 2 Gas A Info COI 3 Co. I 3 Oil A ABC Info

Regola di scrittura Insieme di tutti gli oggetti = Jane COI 2 COI 1 Bank B ABC Info Gas A Info COI 3 Oil A ABC Info

Informazioni “Sanitized” n Alcune informazioni pubbliche possono appartenere ad un CD n n n Essendo pubbliche, non generano conflitti di interesse Tipicamente, tutti i dati sensibili sono rimossi prima che tale informazione sia resa pubblica (l’informazione è “sanitized”) Una terza opzione per la Condizione di sicurezza semplice è quindi: 3. o è un oggetto “sanitized”

Confronto con Bell-La. Padula n Sono fondamentalmente differenti n n n CW non ha etichette di sicurezza, B-LP sì CW si basa sugli accessi passati, B-LP no Bell-La. Padula può simulare CW istante per istante n n Ogni coppia di (COI, CD) è una categoria Due livelli di sicurezza, S (sanitized) and U (non sanitized) n n n S dom U I livelli di sicurezza dei soggetti comprendono al massimo una sola categoria per ogni classe COI Ma B-LP non è in grado di modellare i cambiamenti nel tempo

Confronto con Clark-Wilson n n Il modello di Clark-Wilson si occupa dell’integrità Se i “soggetti” e i “processi” sono la stessa cosa, una singola persona potrebbe usare più processi e violare la condizione di semplice sicurezza in CW n n Ma rispetterebbe il modello di Clark-Wilson Se il “soggetto” è una specifica persona che comprende anche tutti i processi eseguiti, allora CW è consistente con Clark-Wilson Model

Clinical Informazione Systems Securità Policy n Pensato per dati medici n n n Il conflitto di interesse non è un problema critico La confidenzialità del paziente, l’autenticazione dei dati e di chi li scrive, e l’integrità lo sono Entità: n n n Paziente: soggetto dei dati medici Informazioni mediche del paziente: dati sullo stato di salute del paziente o sulle cure mediche possono consentire l’ identificazione del paziente Medici: personale che può entrare in contatto con le informazioni mediche del paziente

Accesso n Principio 1: Ciascuna cartella clinica ha una lista di controllo degli accessi che determina gli individui o i gruppi che possono leggere e aggiungere dati alla cartella. Il sistema deve restringere l’accesso solo alle persone identificate dalla lista. n L’idea è che solo i medici hanno diritto all’accesso, ma nessun altro. Gli auditor possono avere diritto ad una copia, ma non possono fare modifiche

Accesso n Principio 2: Uno dei medici sulla lista dei controlli di accesso ha il diritto di aggiungere persone a tale lista. n E’ chiamato il medico responsabile

Accesso n n Principio 3: Il medico responsabile deve notificare al paziente i nomi sulla lista di controllo quando il record è aperto. Tranne in particolari occasioni, o in casi di emergenza, il medico responsabile deve ottenere il consenso del paziente. Principio 4: Il nome del medico, la data e l’ora di accesso alla cartella clinica deve essere registrato.

Creazione n Principio: Un medico può aprire una cartella clinica, con il medico e il paziente nella lista di controllo accessi. In caso di un referto medico, anche il medico che ha fatto il referto deve stare nella lista.

Cancellazione n Principio: Le informazioni mediche non possono essere cancellate prima che sia passato un determinato lasso di tempo.

Confinamento n n Principio: Le informazioni provenienti da una cartella clinica possono essere aggiunte ad un’altra cartella se e solo se la lista di accesso della seconda cartella è un sottoinsieme della lista della prima. In altri termini chi può accedere alla prima può accedere anche alla seconda

Aggregazione n Principio: Un paziente deve essere messo al corrente se qualcuno è stato aggiunto alla lista di controllo e se questi ha accesso ad un grande numero di cartelle cliniche. n Si evita che un investigatore acceda a molte cartelle, le correli e scopra informazioni private informazione sui singoli individui

Rinforzo n Principio: Tutti i sistemi informatici che trattano dati di cartelle cliniche devono avere un sottosistema che garantisca i precedenti principi. L’effettivo funzionamento di tale sistema deve essere controllato da terze persone.

Confronto con Bell-La. Padula n Il principio di confinamento impone una struttura a “reticolo” sulle entità del modello n n Simile a Bell-La. Padula CISS si concentra sugli oggetti a cui si accede; B-LP sui soggetti che vi accedono

ORCON n n Problema: un’organizzazione vuole controllare la diffusione dei propri documenti Esempio: Il Ministro delle politiche agricole scrive documento da distribuire per i propri impiegati e concede il permesso un’ulteriore ridistribuzione. Ciò si indica con il nome di “originator controlled” (in questo caso, l’ “originator” è una persona).

Requisiti n n Il soggetto s S marca l’oggetto o O come ORCON per conto dell’organizzazione X. X permette che o sia diffuso ai soggetti che lavorano per conto dell’organizzazione Y con le seguenti restrizioni: 1. 2. o non può essere rilasciato a soggetti che lavorano per conto di altre organizzazioni senza il permesso di X e Ogni copia di o deve avere le stesse restrizioni.

DAC non va bene n Il possessore può concedere qualsiasi diritto n La proprietà 2 non sarebbe soddisfatta

MAC non va bene n Primo problema: esplosione del numero delle categorie n n Ogni categoria C contiene o, X, Y. Se un soggetto y Y vuole leggere o ne fa una copia o. Nota che o ha categoria C. Se y vuole dare a z Z una copia, z deve essere in Y ma per definizione non vi è. Se x vuole concedere a w W di vedere il documento, deve creare una nuova categoria C contenente o, X, W. Secondo problema: astrazione n n In MAC la classificazione e le categorie sono controllate centralmente e l’accesso è controllato da una politica centralizzata ORCON è controllato localmente

Combinare DAC e MAC n n Il possessore dell’oggetto non ne può cambiare i controlli di accesso. Quando l’oggetto è copiato, le restrizioni di accesso sono copiate dalla sorgente e legate alla copia. n n Ciò è MAC (il possessore non può controllarlo) Il creatore del documento (originator) può alterare le restrizioni di accesso in base al soggetto e all’oggetto. n Ciò è DAC (l’originator può controllarlo)

RBAC: Motivazioni n n n Un problema importante nell’organizzazione di grandi sistemi è la complessità dell’amministrazione della sicurezza Quando il numero dei soggetti e degli oggetti è alto, il numero di autorizzazioni può diventare molto grande Inoltre, se la popolazione di utenti è molto dinamica, il numero di concessioni e di revoche di permessi diventa eccessivamente elevato

RBAC: Motivazioni n n n Gli utenti finali spesso non “possiedono” le informazioni a cui hanno accesso. Le aziende o gli enti sono i reali possessori degli oggetti Il controllo di accesso è quindi basato sulle mansioni delle persone e non sul semplice possesso RBAC è stato quindi proposto come alternativa al DAC e al MAC per semplificare la gestione degli accessi e per supportare direttamente il controllo basato sulle mansioni (ruoli)

RBAC n I diritti di accesso dipendono dal ruolo, non dall’identità n Esempio: Anna, segreteria del dipartimento, ha accesso ai dati finanziari. n Anna cambia impiego e non ha più diritti di accesso. n Barbara prende il suo posto e adesso è lei che può accedere a quei dati n n E’ il ruolo che stabilisce i diritti e non l’identità del singolo individuo.

RBAC e ruoli n n n I ruoli rappresentano le mansioni all’interno di un’organizzazione Le autorizzazioni sono concesse ai ruoli anzichè ai singoli utenti Gli utenti sono perciò autorizzati semplicemente ad assumere ruoli appropriati, acquisendo le autorizzazioni assegnate a quei ruoli

Vantaggi del RBAC n n n Poichè i ruoli rappresentano le funzioni dell’organizzazione, un modello RBAC può direttamente supportare le politiche di sicurezza proprie dell’organizzazione Concedere e revocare autorizzazioni alle categorie di utenti è grandemente semplificato I modelli RBAC sono perciò “policy-neutral”

RBAC n n I produttori di DBMS hanno visto l’importanza e i vantaggi di RBAC, e oggi molti DBMS commerciali supportano in vario modo RBAC Esiste un certo consenso su un modello standard di RBAC Il modello NIST [Sandhu, Ferraiolo, Kuhn 00] è stato il primo passo verso la definizione di uno standard Una recente definizione è data dall’ ANSI: Role based access control. ANSI INCITS 359 -2004, February 2004

Modello NIST n Tre livelli con capacità funzionali crescenti n n n Core RBAC – anche chiamato Flat RBAC gerarchico RBAC vincolato

RBAC- Concetti di base n n Utente – un essere umano, una macchina, un processo, o un agente intelligente autonomo, ecc. Ruolo – una funzione nel contesto di un’organizzazione con una semantica associata secondo l’autorità e la responsibilità del ruolo

RBAC- Concetti di base n n n Permesso – Modo di accesso che può essere esercitato sugli oggetti nel sistema. Sia gli oggetti e i modi di accesso sono dipendenti dal dominio. Per esempio, nel caso dei database, tra gli oggetti si trovano tabelle, colonne e righe e tra i modi di accesso le operazioni di insert, delete e update.

RBAC- Concetti di base n n Sessione – E’ una particolare istanza di una connessione di un utente al sistema e definisce un sottoinsieme di ruoli attivati. Ad ogni istante, possono essere attive più sessioni differenti per ciascun utente. Quando un utente entra nel sistema, stablisce una sessione e durante tale sessione può attivare un sottoinsieme dei ruoli che è autorizzato ad assumere. L’utente ottiene i permessi associati al ruolo che ha attivato nella sessione.

Role-Based AC Individui Ruoli Risorse ruolo 1 Server 1 ruolo 2 ruolo 3 Server 2 Server 3 Gli utenti cambiano frequentemente, i ruoli no

Core RBAC

Core RBAC - Permissions Operazioni RA Utenti PA Ruoli UA RSA Sessioni Permessi Oggetti

Core RBAC insiemi, funzioni e relazioni n n n USERS, ROLES, OPS, OBS UA ÍUSERS ROLES, relazione molti-a-molti tra utenti e ruoli assigned_users: (r: ROLES) 2 USERS , ad ogni ruolo r l’insieme degli utenti. Formalmente: n n assigned_users(r) = {u USERS | (u, r) UA} PRMS = 2(OPS OBS) , tutti i sottoinsiemi di permessi PA ÍPRMS ROLES, relazione molti-a-molti tra ruoli e permessi assigned_permissions: (r: ROLES) 2 PRMS , ad ogni ruolo l’insieme dei permessi. Formalmente: n assigned_permissions(r) = {p PRMS | (p, r) PA}

Core RBAC n n n insiemi, funzioni e relazioni Op (p : PRMS) {op Í OPS}, le operazioni associate ad un insieme di permess p Ob (p : PRMS) {op Í OBS}, gli oggetti su cui opera un insieme di permessi p SESSIONS = l’insieme delle sessioni session_users (s : SESSIONS) USERS, gli utenti della sessione s session_roles (s : SESSIONS) 2 ROLES, i ruoli degli utenti di una sessione. Formalmente: n n session_roles (s) = {r ROLES | (session_users (s), r) UA} avail_session_perms (s : SESSIONS) 2 PRMS, i permessi disponibili per gli utenti di una sessiona. Formally: n avail_session_perms (s) = È r session_roles( r ) assigned_permissions (r)

Core RBAC - Sessioni n n La nozione di sessione è astratta – è definita “a mapping between a user and an activated subset of roles that are assigned to the user” Distinzioni: n n Attivazione a singolo ruolo (SRA) Solo un ruolo può essere attivo Attivazione a ruoli multipli (MRA) Più ruoli possono essere attivi in una sessione, è possibile vincolare la concorrente presenza di alcuni ruoli

RBAC gerarchico - Motivazioni n Le gerarchia tra ruoli sono un modo naturale per strutturare i ruoli in modo da riflettere le linee di autorità e responsibilità di un’organizzazione

Modello gerarchico RBAC - - RH Í ROLES è una relazione binaria non riflessiva e aciclica sull’insieme of ruoli nel sistema E’ una relazione di dominanza; se (ri, rj) RH diremo che ri domina rj La relazione ³ è la chiusura riflessiva e transitiva di RH. Un sistema RBAC può scegliere se memorizzare ³ o se calcolarlo ogni volta

Esempio di RH Director Project Lead 1 Produczione Engineer 1 Project Lead 2 Qualità Engineer 1 Produczione Engineer 2 Engineer 1 Qualità Engineer 2 Engineering Dept

Semantica del RBAC gerarchico n n n Ereditarietà di utente (UI): Tutti gli utenti autorizzati ad un ruolo r sono anche autorizzati ad un ruolo r’, ove r ³ r’ Eredità di permessi (PI): Un ruolo r è autorizzato a tutti i permessi per i quali ogni ruolo r’, tale che r ³ r’, è autorizzato Eredità di attivazione (AI): Attivando un ruolo r automaticamente si attivano tutti i ruoli r’, tali che r ³ r’. Da usare solo con sessioni MRA

RBAC vincolato n n n Il RBAC vincolato è un modello RBAC con la capacità di supportare le politiche di Separazione dei compiti (Separation of Duty) Evita conflitti di interesse e collisioni tra mansioni Due categorie principali: n n So. D statici So. D dinamici

RBAC –So. D statici n n n So. D statici restringono l’insieme dei ruoli and in particolare la possobilità ad entrare nella relazione RA Nessun utente può assumere più di t ruoli in un insieme di m ruoli Evita che una persona sia autorizzata a usare troppi ruoli

RBAC –So. D Dinamici n n Questi vincoli limitano il numero di ruoli che un utente può attivare in una singola sessione Esempi di vincoli: n n n Nessun utente può attivare più di t ruoli nel corso di una sessione. se l’utente ha usato il ruolo r 1 in una sessione, non può usare il ruolo r 2 nella stessa sessione E’ necessario mantenere una storia dei ruoli attivati da ciascun utente

Constraint RBAC Prepare check Static SOD Approve/ Disapprove check Dynamic SOD Summarize decisions Approve/ Disapprove check Issue/void check

Autenticazione n Autenticazione: collegamento soggetto-identità n n L’identità si riferisce ad un’entità esterna (Marco Baioletti, . . . ) Il soggetto è un entità del sistema (utente, processo, . . . )

Stabilire un’identità n Mediante uno o più tra n n Un’informazione che l’entità possiede (ad es. password) Un’oggetto fisico che l’entità ha (ad es. badge, smart card) Una caratteristica che l’entità possiede (ad es. impronte digitali, caratteristiche della retina) Una situazione/luogo in cui l’entità si trova (ad es. di fronte ad un determinato terminale)

Sistema di autenticazione n (A, C, F, L, S) n n n A informazione riguardante l’identità C informazione memorizzata e usata per validare l’informazione di autenticazione F funzioni complementari; f : A C L funzioni che comprovano l’identità S funzioni che permettono alle entità di creare e alterare informazioni in A o C

(Cattivo) esempio n Sistema di password in cui le password sono memorizzate in chiaro n n n A insieme di stringhe (password) C=A F = { identità } L = { uguaglianza } S funzioni tipo passwd

Password n n Una password è un’informazione testuale associata ad un’entità che ne conferma l’identità Sequenze di caratteri n n n Sequenze di parole n n Esempi: 10 cifre, una stringa di lettere, ecc. Generata a caso, dall’utente, dal computer su input dell’utente Esempi: pass-phrases Algoritmi n Esempi: challenge-response, one-time passwords

Memorizzazione di password n Memorizzate in chiaro n n File cifrato n n n Se il file delle password è compromesso, tutte le password sono rivelate Deve essere decifrato, la chiave di cifratura è in memoria Alla fine si riconduce al problema precedente ! Memorizzate con funzioni hash one-way n Se il file viene letto, l’attaccante deve comunque indovinare le password o invertire la funzione hash

Esempio n UNIX usa delle funzioni hash n n Comprime le password in una stringa di 11 carattery (88 byte) usando una tra 4096 funzioni hash Come sistema di autenticazione: n n n A = { stringhe di <= 8 caratteri } C = { 2 car. hash id || 11 car. hash } F = { 4096 versioni di DES } L = { login, su, … } S = { passwd, nispasswd, passwd+, … }

Anatomia dell’attacco n Scopo: trovare a A tale che: n n n Due modi per vedere se a soddisfa questi requisiti: n n n Per qualche f F, f(a) = c C c è associata ad un’entità particolare (o a qualsiasi entità) Approccio diretto: calcolare f(a) Approccio indiretto: vedere il risultato di l(a) Altro tipo di attacco: mediante il social engineering acquisire informazioni sull’utente e da queste trovare buoni candidati come password

Prevenire gli attacchi n Come prevenire questo: n Nascondere a, f, o c Previente gli attacchi diretti n Esempio: UNIX/Linux shadow password files n n n Nascondono c Bloccare l’accesso a tutte le l L o al risultato di l(a) L’attaccante non sa se ha indovinato n Esempio: disabilitare l’accesso dalla rete, oppure rallentare la risposta n

Attacchi mediante dizionario n Tentativi mediante una lista D di parole note (dizionario) n Off-line: Sapendo f e c, si provano tutti i tentativi g D finchè la lista non è finita o non si è trovata la password n n Esempi: crack, john-the-ripper On-line: avere accesso alle funzioni in L e fare i tentativi g fino a che l(g) è vera n Esampi: prova a fare login indovinando la password

Quanto tempo ? Formula di Anderson: n P probabilità di indovinare una password in uno specificato periodo di tempo n G numero di tentativi nell’unità di tempo n T numero di unità di tempo n N numero di password possibili (|A|) n Allora P ≥ TG/N

Esempio n Scopo n n n Password composte da un insieme di 96 caratteri 104 tentativi al secondo Probabilità di successo pari a 0. 5 su 365 giorni Qual è la lunghezza minima s della password? Soluzione n n n N ≥ TG/P = (365 24 60 60) 104/0. 5 = 6. 31 1011 Scegliere s tale che sj=0 96 j ≥ N Perciò s ≥ 6

Modi di selezionare le password n Password generate completamente a caso n n Vantaggio: ogni password ha la stessa probabilità di essere generata Svantaggio: non sono ricordabili Password “pronunciabili” Password selezionate dall’utente

Password Pronunciabili n n Generare fonemi a caso n Il fonema è un’unità fonetica, per esempio consonante+vocale, v+c, c+v+c, v+c+v n Esempi: n helgoret, juttelon SI n przbqxdfl, zxrptglfn NO Problema: sono troppo poche

Selezione da parte dell’utente n Problema: si è portati a scegliere password semplici (da ricordare) n n n Basati sul nomi di account, sul proprio nome e cognome, sul nome del computer, sui luoghi Parole di dizionario (anche al contrario, con maiuscole/minuscole invertite, caratteri di controllo, “elite-speak”, coniugazioni o declinazioni di parole, parolacce, Torah/Bibbia/Corano/… ) Troppo corte, solo cifre, solo lettere Targhe di macchine, acronimi, social security numbers Caratteristiche personali (nomi di animali, soprannomi, caratteristiche di lavoro, ecc. )

Buone password n “Ll. Mm*2^Ap” n n “Oo. He. O/FSK” n n Second letter of each word of length 4 or more in third line of third verse of Star-Spangled Banner, followed by “/”, followed by author’s initials Non sempre sono buone n n Names of members of 2 families “DMC/MHmh” non va bene a Dartmouth (“Dartmouth Medical Center/Mary Hitchcock memorial hospital”), in altri posti è OK Adesso sono cattive password ?

Controllo proattivo delle password n Analizza le password n n n Da invocare sempre Può scoprire e rifiutare password cattive Discrimina in base all’utente e al sito Fa pattern matching sulle parole Deve eseguire sottoprogrammi e usare i risultati n n Spell checker Facile da integrare con i sistemi di modifica password

Esempio: OPUS n Scopo: controllare le password in modo veloce su un dizionario di grandi dimensioni n n n Calcolare per ogni parola del dizionario k funzioni hash differenti h 1, …, hk, ognuna delle quali un valore minore di n calcolare h 1, …, hk per tutte le parole del dizionario e da questo generare un vettore di n bit D Per controllare una parola, generare il vettore di bit e vedere se tutti i bit 1 della parola corrispondono ai bit 1 di D n n in caso positivo, c’è una certa probabilità che la parola appartiene al dizionario in caso negativo, non appartiene al dizionario

Esempio: passwd+ n Fornisce un linguaggio per descrivere i controlli proattivi n test length(“$p”) < 6 n n test infile(“/usr/dict/words”, “$p”) n n se la password ha meno di 6 caratteri, rifiutala se la password fa parte del file /usr/dict/words, rifiutala test !inprog(“spell”, “$p”) n se la password non viene corretta dal correttore ortografico, rifiutala (perché è una parola scritta correttamente)

Salting n n Scopo: rallentare gli attacchi basati sul dizionario Metodo: perturbare le funzioni hash con un parametro “salt” n n n Il “salt” controlla quale funzione hash è usata Il “salt” è diverso per ogni password Con n possibili password hashes, e quindi n valori di “salt”, l’attaccante deve provare n valori hash per ogni tentativo di password

Esempi n Metodo di base in UNIX n n Usare DES per cifrare il messaggio nullo con la password come chiave Perturbare la tabella E di DES in uno tra 4096 modi possibili n n i 12 bit del salt invertono le entrate 1– 11 con le entrate 25– 36 Metodi alternative n Usare il salt come prima parte dell’input della funzione hash

Tentativi attraverso L n n Non si possono prevenire del tutto n Altrimenti nemmeno gli utenti legittimi potrebbero log in Però si possono rallentare n Backoff esponenziale n Disconnessione dopo n tentativi falliti n Disabilitazione dopo n tentativi falliti n Attenzione agli account di amministratore! n Jailing n Farlo entrare, ma in un ambiente ristretto e così magari viene identificato

Password Aging n n Forzare gli utenti a cambiare la password dopo un certo periodo Dopo un certo lasso di tempo la password potrebbe essere stata violata n Come si forzano gli utenti a non riutilizzare le password? n n n Memorizzare le password precedenti Bloccare i cambiamenti per un tempo minimo Dare agli utenti tempo sufficiente a trovare buone password n n Non forzarli a cambiarla prima del login Avvisarli prima della scadenza

Challenge-Response • L’utente e il sistema condividono una funzione segreta f (in pratica, f è una funzione nota con parametri incogniti come una chiave crittografica) request to authenticate system user random message r (the challenge) system user f(r) (the response) system user

Pass Algorithms n Challenge-response con una funzione segreta f n Esempio: n n n La Challenge è una stringa casuale: “abcdefg”, “ageksido” La Response è una funzione della stringa: ad esempio una lettera sì, una no a partire dalla seconda: “bdf”, “gkio” Si possono usare modi diversi a seconda della sicurezza n ad esempio in un’area poco sicura la risposta potrebbe aggiungere (in posizioni concordate) caratteri a caso: “xbydmfg”

One-Time Password n n n Password che possono essere usate solo una volta n Dopo l’uso sono immediatamente invalidate Meccanismo Challenge-response n Challenge è il numero progressivo di autenticazioni; response è la password per quel particolare numero Problemi n Sincronizzazione tra l’utente e il sistema n Generazione di buone password casuali n Distribuzione delle password

S/Key n n Schema di One-time password basato sull’idea di Lamport h funzione hash one-way (ad esempio MD 5 o SHA-1) L’utente sceglie un valore iniziale k Il sistema calcola: h(k) = k 1, h(k 1) = k 2, …, h(kn– 1) = kn n Le password sono in ordine inverso: p 1 = kn, p 2 = kn– 1, …, pn– 1 = k 2, pn = k 1

Protocollo S/Key Il sistema si memorizza • il massimo numero di autenticazioni n, • il numero della prossima autenticazione i, • l’ultima password correttamente fornita pi– 1. user { name } {i} { pi } system Il sistema calcola h(pi) = h(kn–i+1) = kn–i = pi– 1. Se corrisponde con quello che è memorizzato, sostituisce pi– 1 con pi e incrementa i.

Supporto Hardware n Basato sui Token n Un dispositivo fisico usato per calcolare la risposta al challenge Può cifrare o calcolare una funzione hash della challenge n Può richiedere un PIN all’utente n n Basato sul tempo n Ogni tot di tempo mostra un numero diverso n n Il sistema quale numero sarà mostrato L’utente immette il numero e la password

Biometria n Misure automatiche di caratteristiche biologiche o di comportamento che identificano una persona n Impronte digitali: tecniche ottiche o elettriche n n n L’impronta è tradotta in un grafo, che poi è ricercato in un database Le misure sono imprecise, perciò sono necessari algoritmi di matching approssimati Voce: verifica/riconoscimento del parlante n n Verifica: si usano tecniche statistiche per verificare se il parlante è veramente lui (dipendono dall’utente) Riconoscimento: riconosce una parola o una frase particolari, tipo password vocale (indipendenti dall’utente)

Altre caratteristiche n Si possono usare altre caratteristiche n Occhi: pattern unici nell’iride n n n Faccia: immagine o caratteristiche specifiche come la distanza dal naso al mento n n trova il pattern e lo confronta con quelle memorizzate, determinando se le differenze sono casuali un’alternativa è usare test statistici di correlazione difficoltà possono sorgere dai capelli, luce, posizione, ecc. Dinamica di digitazione (forse è univoca) n n Intervallo di battitura tasti, pressione, durata del colpo Si usano test statistici

Attenzione, però n Ci sono molti modi per frodare questi sistemi ! n n Verificare che gli strumenti biometrici siano accurati nell’ambiente in cui sono usati! Accertarsi che la trasmissione dei dati al sistema sia corretta e a prova di manomissione

Luogo/situazione n Se si sa dove si dovrebbe trovare un utente, l’identità può essere verificata controllando se la persona è realmente lì n E’ richiesto un hardware speciale per localizzare gli utenti Il GPS fornisce una “location signature” della posizione dell’entità n Gli host usano gli LSS (location signature sensor) per localizzare il punto di accesso n

Metodi multipli n n Esempio: il “dove sei” richiede all’utente di avere un dispositivo GPS, perciò è anche un metodo “cosa hai” Si possono assegnare più modi di autenticazione n Se un utente deve compiere un’azione più importante si deve autenticare in modo più stringente

PAM n Idea: se un programma ha bisogno di far autenticare un utente, chiama la routine pam_authenticate n n Accede ad un file di configurazione nella cartella /etc/pam_d avente lo stesso nome del programma Il file contiene i moduli di autenticazione che devono essere chiamati e come usare i risultati che restituiscono n n sufficient: ha successo se il modulo ha esito positivo required: fallisce se il metodo ha esito negativo, ma tutti i metodi precedenti sono comunque chiamati requisite: come required, ma non controlla gli altri moduli optional: invocato solo se tutti gli altri falliscono

Esempio di file PAM auth sufficient auth required /usr/lib/pam_ftp. so /usr/lib/pam_unix_auth. so use_first_pass /usr/lib/pam_listfile. so onerr=succeed item=user sense=deny file=/etc/ftpusers Quando si lancia ftp: 1. Se l’utente è “anonymous”, è accettate; altrimenti poni PAM_AUTHTOK = password, PAM_RUSER = nome e fallisci 2. Ora controlla che la password in PAM_AUTHTOK appartiene a quella dell’utente in PAM_RUSER; in caso contrario fallisci 3. Infine se l’utente in PAM_RUSER è presente in /etc/ftpusers (utenti che non si possono usare per ftp) fallisci altrimenti accetta

Studio sulle password (Stallings, 2003) Collected nearly 14, 000 encrypted passwords n Strategia: ● Try user info variants ● Try words from 60, 000 entry dictionary ● Try permutations of above (0 -O, 1 -L, etc. ) ● Try various capitalization of above ● Table Next slide n