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 Politiche per l’integrità Politiche ibride Autenticazione

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

I requisiti di integrità di Lipner 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à I requisiti suggeriscono i seguenti principi 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à Modello di Biba 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 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 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 o0 → s1 → o1 → s2 → o2 →....→ sn → on l’integrità dell’oggetto finale è minore o uguale di quello di partenza

LOCUS e Biba Scopo: prevenire che un programma non fidati alteri dati o altri programmi Approccio: usare livelli di fiducia 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 Lipner è riuscito a coniugare Bell-La Padula (confidenzialità) e Biba (integrità) Un soggetto s può leggere un oggetto o se 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à Tre livelli di integrità: 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à ID (Development): entità in sviluppo IP (Produczione): entità di produzione

Livelli/categorie di sicurezza Due Livelli di sicurezza AM (Audit Manager): system audit, funzioni di amministrazione SL (System Low): ogni processo può leggere tali dati Tre Categorie di sicurezza 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 }) System managers and auditors (AM, { SP, SD, SSD }) (ISL, { IP, ID}) System controllers (SL, { SP, SD }) and downgrade privilege (ISP, { IP, ID}) Repair

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

Utenti ordinari Un utente ordinario ha i livelli: sicurezza (SL, { SP }) integrità (ISL, { IP }) Quindi può svolgere le seguenti operazioni 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 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 Adatto all’integrità dei database L’integrità definita mediante vincoli che i dati devono rispettare Esempio: in una banca 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à 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 CR1 Se un IVP è eseguito, deve assicurarsi che tutti i CDI siano in uno stato valido CR2 Una TP deve trasformare un insieme di CDI da uno stato valido ad uno stato valido CR2 definisce come certificata una relazione che associa un insieme di CDI ad una TP CR2 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, account1), (balance, account2),…., (balance, accountn) Î C

Regole di rinforzo CR2 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 ER1 Il sistema deve garantire che solo le TP certificate ad operare su determinati CDI svolgano operazioni su di essi. ER2 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. 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 CR3 Le relazioni di permesso devono essere basate sulla separazione dei compiti. ER3 Il sistema deve autenticare ogni utente che vuole utilizzare una TP

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

Trattamento di Input non fidato CR5 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. 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 ER4 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 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

Conflitto di interessi E’ un concetto ben noto (...) Un esempio nel mondo finanziario è quello di un analista che lavora come consulente presso l’azienda X Tale analista deve tenere fede ai requisiti di confidentialità delle informazioni che l’azienda X pone su di lui: non può usare tali informazioni con un’azienda rivale di X Comunque l’analista è libero di usare tali informazioni con aziende non in competizione con X

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 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 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 (CoI): compagnie rivali di una data compagnia

Definizioni 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 CoI 1 CoI 2 CoI 3 Bank A Bank B Gas A Oil A Oil B Info Info

Evoluzione dei diritti 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 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 Un soggetto s può leggere un oggetto o se e solo se: 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

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

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

Confronto con Bell-LaPadula 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 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 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 Un soggetto s può scrivere un oggetto o se e solo se entrambe le condizioni valgono 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

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

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 Inoltre, una volta che ha scritto in un dataset, può scrivere solo lì

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

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

Informazioni “Sanitized” Alcune informazioni pubbliche possono appartenere ad un CD 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-LaPadula Sono fondamentalmente differenti CW non ha etichette di sicurezza, B-LP sì CW si basa sugli accessi passati, B-LP no Bell-LaPadula può simulare CW istante per istante Ogni coppia di (COI, CD) è una categoria Due livelli di sicurezza, S (sanitized) and U (non sanitized) 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 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 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 Pensato per dati medici 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à: Paziente: soggetto dei dati medici Informazioni mediche del paziente: dati sullo stato di salute del paziente o sulle cure mediche che possono consentire l’ identificazione del paziente Medici: personale che può entrare in contatto con le informazioni mediche del paziente

Accesso 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. 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 Principio 2: Uno dei medici sulla lista dei controlli di accesso ha il diritto di aggiungere persone a tale lista. E’ chiamato il medico responsabile

Accesso 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 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 Principio: Le informazioni mediche non possono essere cancellate prima che sia passato un determinato lasso di tempo.

Confinamento 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 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. Si evita che un investigatore acceda a molte cartelle, le correli e scopra informazioni private informazione sui singoli individui

Rinforzo 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-LaPadula Il principio di confinamento impone una struttura a “reticolo” sulle entità del modello Simile a Bell-LaPadula CISS si concentra sugli oggetti a cui si accede; B-LP sui soggetti che vi accedono

ORCON 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 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: 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 Il possessore può concedere qualsiasi diritto La proprietà 2 non sarebbe soddisfatta

MAC non va bene Primo problema: esplosione del numero delle categorie 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 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 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. 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. Ciò è DAC (l’originator può controllarlo)

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

RBAC e ruoli 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 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 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 Tre livelli con capacità funzionali crescenti Core RBAC – anche chiamato Flat RBAC RBAC gerarchico RBAC vincolato

RBAC- Concetti di base 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 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 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 ruolo 2 ruolo 3 Server 1 Gli utenti cambiano frequentemente, i ruoli no

Core RBAC

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

Core RBAC insiemi, funzioni e relazioni USERS, ROLES, OPS, OBS UA ÍUSERS ´ ROLES, relazione molti-a-molti tra utenti e ruoli assigned_users: (r: ROLES) ® 2USERS , ad ogni ruolo r l’insieme degli utenti. Formalmente: 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) ® 2PRMS , ad ogni ruolo l’insieme dei permessi. Formalmente: assigned_permissions(r) = {p Î PRMS | (p, r) Î PA}

Core RBAC 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) ® 2ROLES, i ruoli degli utenti di una sessione. Formalmente: session_roles (s) = {r Î ROLES | (session_users (s), r) Î UA} avail_session_perms (s : SESSIONS) ® 2PRMS, i permessi disponibili per gli utenti di una sessiona. Formally: avail_session_perms (s) = È r Î session_roles( r ) assigned_permissions (r)

Core RBAC - Sessioni La nozione di sessione è astratta – è definita “a mapping between a user and an activated subset of roles that are assigned to the user” Distinzioni: 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 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 ´ 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 Project Lead 2 Produczione Engineer 1 Qualità Engineer 1 Produczione Engineer 2 Qualità Engineer 2 Engineer 1 Engineer 2 Engineering Dept

Semantica del RBAC gerarchico 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 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: SoD statici SoD dinamici

RBAC –SoD statici SoD 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 –SoD Dinamici Questi vincoli limitano il numero di ruoli che un utente può attivare in una singola sessione Esempi di vincoli: Nessun utente può attivare più di t ruoli nel corso di una sessione. se l’utente ha usato il ruolo r1 in una sessione, non può usare il ruolo r2 nella stessa sessione E’ necessario mantenere una storia dei ruoli attivati da ciascun utente

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

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

Stabilire un’identità Mediante uno o più tra 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 (A, C, F, L, S) 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 Sistema di password in cui le password sono memorizzate in chiaro A insieme di stringhe (password) C = A F = { identità } L = { uguaglianza } S funzioni tipo passwd

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

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

Esempio UNIX usa delle funzioni hash Come sistema di autenticazione: Comprime le password in una stringa di 11 carattery (88 byte) usando una tra 4096 funzioni hash Come sistema di autenticazione: 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 Scopo: trovare a  A tale che: Per qualche f  F, f(a) = c  C c è associata ad un’entità particolare (o a qualsiasi entità) Due modi per vedere se a soddisfa questi requisiti: 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 Come prevenire questo: Nascondere a, f, o c Previente gli attacchi diretti Esempio: UNIX/Linux shadow password files Nascondono c Bloccare l’accesso a tutte le l  L o al risultato di l(a) L’attaccante non sa se ha indovinato Esempio: disabilitare l’accesso dalla rete, oppure rallentare la risposta

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

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

Esempio Scopo Soluzione 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 ≥ TG/P = (365246060)104/0.5 = 6.311011 Scegliere s tale che sj=0 96j ≥ N Perciò s ≥ 6

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

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

Selezione da parte dell’utente Problema: si è portati a scegliere password semplici (da ricordare) 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 “LlMm*2^Ap” “OoHeO/FSK” Non sempre sono buone Names of members of 2 families “OoHeO/FSK” 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 “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 Analizza le password 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 Spell checker Facile da integrare con i sistemi di modifica password

Esempio: OPUS Scopo: controllare le password in modo veloce su un dizionario di grandi dimensioni Calcolare per ogni parola del dizionario k funzioni hash differenti h1, …, hk, ognuna delle quali un valore minore di n calcolare h1, …, 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 in caso positivo, c’è una certa probabilità che la parola appartiene al dizionario in caso negativo, non appartiene al dizionario

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

Salting Scopo: rallentare gli attacchi basati sul dizionario Metodo: perturbare le funzioni hash con un parametro “salt” 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 Metodo di base in UNIX Metodi alternative Usare DES per cifrare il messaggio nullo con la password come chiave Perturbare la tabella E di DES in uno tra 4096 modi possibili i 12 bit del salt invertono le entrate 1–11 con le entrate 25–36 Metodi alternative Usare il salt come prima parte dell’input della funzione hash

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

Password Aging Forzare gli utenti a cambiare la password dopo un certo periodo Dopo un certo lasso di tempo la password potrebbe essere stata violata Come si forzano gli utenti a non riutilizzare le password? Memorizzare le password precedenti Bloccare i cambiamenti per un tempo minimo Dare agli utenti tempo sufficiente a trovare buone password 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 user system random message r (the challenge) user system f(r) (the response) user system

Pass Algorithms Challenge-response con una funzione segreta f Esempio: 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 ad esempio in un’area poco sicura la risposta potrebbe aggiungere (in posizioni concordate) caratteri a caso: “xbydmfg”

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

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

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. { name } user system { i } user system { pi } user 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 Basato sui Token Basato sul tempo Un dispositivo fisico usato per calcolare la risposta al challenge Può cifrare o calcolare una funzione hash della challenge Può richiedere un PIN all’utente Basato sul tempo Ogni tot di tempo mostra un numero diverso Il sistema quale numero sarà mostrato L’utente immette il numero e la password

Biometria Misure automatiche di caratteristiche biologiche o di comportamento che identificano una persona Impronte digitali: tecniche ottiche o elettriche 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 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 Si possono usare altre caratteristiche Occhi: pattern unici nell’iride trova il pattern e lo confronta con quelle memorizzate, determinando se le differenze sono casuali un’alternativa è usare test statistici di correlazione Faccia: immagine o caratteristiche specifiche come la distanza dal naso al mento difficoltà possono sorgere dai capelli, luce, posizione, ecc. Dinamica di digitazione (forse è univoca) Intervallo di battitura tasti, pressione, durata del colpo Si usano test statistici

Attenzione, però Ci sono molti modi per frodare questi sistemi ! 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 Se si sa dove si dovrebbe trovare un utente, l’identità può essere verificata controllando se la persona è realmente lì E’ richiesto un hardware speciale per localizzare gli utenti Il GPS fornisce una “location signature” della posizione dell’entità Gli host usano gli LSS (location signature sensor) per localizzare il punto di accesso

Metodi multipli 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 Se un utente deve compiere un’azione più importante si deve autenticare in modo più stringente

PAM Idea: se un programma ha bisogno di far autenticare un utente, chiama la routine pam_authenticate 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 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 Quando si lancia ftp: auth sufficient /usr/lib/pam_ftp.so auth required /usr/lib/pam_unix_auth.so use_first_pass auth required /usr/lib/pam_listfile.so onerr=succeed \ item=user sense=deny file=/etc/ftpusers Quando si lancia ftp: Se l’utente è “anonymous”, è accettate; altrimenti poni PAM_AUTHTOK = password, PAM_RUSER = nome e fallisci Ora controlla che la password in PAM_AUTHTOK appartiene a quella dell’utente in PAM_RUSER; in caso contrario fallisci 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 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