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
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à

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 })
(ISL, { ID })
System managers and
auditors
(AM, { SP, SD, SSD })
(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

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
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 2
CoI 1
Bank A
Info
Info
Bank B
Info
Info
Info
CoI 3
Gas A
Oil A
Info
Info
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:
1.
2.


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:
 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
Bank A
R
R
Gas A
Consultant
R
X
R
R
Oil B
Bank B
Regola di lettura
= John
Insieme di tutti gli oggetti
CoI 2
COI
CoI 11
Bank A
Info
Info
Info
Bank B
Info
Info
COI
CoI 33
Gas A
Oil A
Info
Info
Oil B
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
1.
2.

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
 lo può anche leggere E
 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
 Inoltre, una volta che ha scritto in un dataset, può
scrivere solo lì

Regola di scrittura
= John
COI
CoI 11
Bank A
Info Info
ABC
Info
Insieme di tutti gli oggetti
CoI 2
Gas A
Info
COI
CoI 33
Oil A
ABC Info
Regola di scrittura
Insieme di tutti gli oggetti
= Jane
COI 2
COI 1
Bank B
ABC Info
Info
Gas A
Info
COI 3
Oil A
ABC 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:
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

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
Server 1
ruolo 2
ruolo 3
Server 2
Server 3
Gli utenti cambiano frequentemente, i ruoli no
Core RBAC
RA
Users
PA
Roles
UA
RSA
Sessions
Permissions
Core RBAC - Permissions
Operazioni
RA
Utenti
PA
Ruoli
UA
RSA
Sessioni
Permessi
Oggetti
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
Produczione
Engineer 1
Project Lead 2
Qualità
Engineer 1
Produczione
Engineer 2
Engineer 1
Qualità
Engineer 2
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
Prepare
check
Static SOD
Approve/
Disapprove
check
Dynamic SOD
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



Sequenze di parole


Esempi: 10 cifre, una stringa di lettere, ecc.
Generata a caso, dall’utente, dal computer su input
dell’utente
Esempi: pass-phrases
Algoritmi

Esempi: challenge-response, one-time passwords
Memorizzazione di password

Memorizzate in chiaro


File cifrato



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

Se il file viene letto, l’attaccante deve comunque
indovinare le password o invertire la funzione hash
Esempio

UNIX usa delle funzioni hash


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:



Due modi per vedere se a soddisfa questi requisiti:



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

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





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”


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


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

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


test infile(“/usr/dict/words”, “$p”)


se la password ha meno di 6 caratteri, rifiutala
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


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
system
user
random message r
(the challenge)
system
user
f(r)
(the response)
system
user
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
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.
user
user
user
{ name }
{i}
{ pi }
system
system
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

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



Faccia: immagine o caratteristiche specifiche come la
distanza dal naso al mento


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)


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
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:
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
 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
