Sicurezza Informatica

1
Sicurezza Informatica

• Prof. Stefano Bistarelli
• bista_at_dipmat.unipg.it
• http//www.sci.unich.it/bista/

2
Chapter 7 Hybrid Policies

• Overview
• Chinese Wall Model
• ORCON
• RBAC

3
Overview

• Chinese Wall Model
• Focuses on conflict of interest
• ORCON
• Combines mandatory, discretionary access controls
• RBAC
• Base controls on job function

4
Chinese Wall Model

• Problem
• Tony advises American Bank about investments
• He is asked to advise Toyland Bank about
  investments
• Conflict of interest to accept, because his
  advice for either bank would affect his advice to
  the other bank

5
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 lutente
  ha già avuto accesso

6
Organization

• Organize entities into conflict of interest
  classes
• Control subject accesses to each class
• Control writing to all classes to ensure
  information is not passed along in violation of
  rules
• Allow sanitized data to be viewed by everyone

7
Definitions

• Objects items of information related to a
  company
• Company dataset (CD) contains objects related to
  a single company
• Written CD(O)
• Conflict of interest class (COI) contains
  datasets of companies in competition
• Written COI(O)
• Assume each object belongs to exactly one COI
  class

8
Classificazione dei dati
Insieme di tutti gli oggetti
CoI 2
CoI 1
CoI 3
Bank A
Bank B
Gas A
Oil A
Oil B
9
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) linsieme degli oggetti che
  S ha già letto

10
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 allinizio

11
In altri termini

• Un soggetto può leggere un oggetto se
• loggetto è in un dataset di cui il soggetto ha
  già letto qualcosa oppure
• loggetto 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
12
Regola di lettura
John
Insieme di tutti gli oggetti
CoI 2
COI 1
COI 3
CoI 1
Bank A
Gas A
Oil A
Bank A
Info
Info
Info
Info
Info
Info
13
Confronto con Bell-LaPadula

• La politica Chinese Wall è una combinazione di
  libera scelta e MAC
• Inizialmente un soggetto è libero di accedere a
  ciò che vuole
• Una volta fatta la scelta, per quellutente è
  creata una Muraglia Cinese attorno al dataset a
  cui loggetto appartiene
• Si noti che la Chinese Wall può essere combinata
  con le politiche DAC

14
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

15
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

16
In altri termini

• Un soggetto può scrivere un oggetto se
• lo può anche leggere E
• non può leggere dati di altre compagnie

ConsultantA
X
W
Bank B
R
Oil B
X
ConsultantB
W
R
Bank A
17
Conclusioni e critiche

• Perciò secondo questa regola
• Il flusso di informazioni è confinato
  allinterno 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ì

18
Regola di scrittura
Insieme di tutti gli oggetti
John
CoI 2
COI 1
COI 3
CoI 3
CoI 1
Bank A
Bank A
Gas A
Oil A
Oil A
Info
Info
Info
Info
Info
Info
Info
ABC
19
Regola di scrittura
Insieme di tutti gli oggetti
Jane
COI 2
COI 1
COI 3
COI 3
COI 1
Gas A
Oil A
Bank B
Oil A
Bank B
Info
Info
Info
Info
Info
Info
ABC
20
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
  (linformazione è sanitized)
• Una terza opzione per la Condizione di sicurezza
  semplice è quindi
• o è un oggetto sanitized

21
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

22
Compare to Bell-LaPadula

• Bell-LaPadula cannot track changes over time
• Susan becomes ill, Anna needs to take over
• C-W history lets Anna know if she can
• No way for Bell-LaPadula to capture this
• Access constraints change over time
• Initially, subjects in C-W can read any object
• Bell-LaPadula constrains set of objects that a
  subject can access

23
Confronto con Clark-Wilson

• Il modello di Clark-Wilson si occupa
  dellintegrità
• 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

24
orcon
25
ORCON

• Problema unorganizzazione 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 unulteriore
  ridistribuzione. Ciò si indica con il nome di
  originator controlled (in questo caso, l
  originator è una persona).

26
Requisiti

• Il soggetto s ? S marca loggetto o ? O come
  ORCON per conto dellorganizzazione X.
• X permette che o sia diffuso ai soggetti che
  lavorano per conto dellorganizzazione 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.

27
DAC non va bene

• Il possessore (owner) può concedere qualsiasi
  diritto
• La proprietà 2 non sarebbe soddisfatta

28
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 laccesso è
  controllato da una politica centralizzata
• ORCON è controllato localmente

29
Combinare DAC e MAC

• Il possessore delloggetto non ne può cambiare i
  controlli di accesso.
• Quando loggetto è copiato, le restrizioni di
  accesso sono copiate dalla sorgente e legate alla
  copia.
• Ciò è MAC (lowner non può controllarlo)
• Il creatore del documento (originator) può
  alterare le restrizioni di accesso in base al
  soggetto e alloggetto.
• Ciò è DAC (loriginator/owner può controllarlo)

30
rbac
31
RBAC Motivazioni

• Un problema importante nellorganizzazione di
  grandi sistemi è la complessità
  dellamministrazione 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

32
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)

33
RBAC

• I diritti di accesso dipendono dal ruolo, non
  dallidentità
• 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
  lidentità del singolo individuo.

34
RBAC e ruoli

• I ruoli rappresentano le mansioni allinterno di
  unorganizzazione
• 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

35
Vantaggi del RBAC

• Poichè i ruoli rappresentano le funzioni
  dellorganizzazione, un modello RBAC può
  direttamente supportare le politiche di sicurezza
  proprie dellorganizzazione
• Concedere e revocare autorizzazioni alle
  categorie di utenti è grandemente semplificato
• I modelli RBAC sono perciò policy-neutral

36
RBAC

• I produttori di DBMS hanno visto limportanza 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

37
Modello NIST

• Tre livelli con capacità funzionali crescenti
• Core RBAC anche chiamato Flat RBAC
• RBAC gerarchico
• RBAC vincolato

38
RBAC- Concetti di base

• Utente un essere umano, una macchina, un
  processo, o un agente intelligente autonomo, ecc.
• Ruolo una funzione nel contesto di
  unorganizzazione con una semantica associata
  secondo lautorità e la responsibilità del ruolo

39
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.

40
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.
• Lutente ottiene i permessi associati al ruolo
  che ha attivato nella sessione.

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

• Role r collection of job functions
• trans(r) set of authorized transactions for r
• Active role of subject s role s is currently in
• actr(s)
• Authorized roles of a subject s set of roles s
  is authorized to assume
• authr(s)
• canexec(s, t) iff subject s can execute
  transaction t at current time

43
Axioms

• Let S be the set of subjects and T the set of
  transactions.
• Rule of role assignment (?s ? S)(?t ? T)
  canexec(s, t) ? actr(s) ? ?.
• If s can execute a transaction, it has a role
• This ties transactions to roles
• Rule of role authorization (?s ? S) actr(s)
  ? authr(s).
• Subject must be authorized to assume an active
  role (otherwise, any subject could assume any
  role)

44
Axiom

• Rule of transaction authorization (?s ? S)(?t ?
  T) canexec(s, t) ? t ? trans(actr(s)).
• If a subject s can execute a transaction, then
  the transaction is an authorized one for the role
  s has assumed

45
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
  unorganizzazione

46
Containment of Roles

• Trainer can do all transactions that trainee can
  do (and then some). This means role r contains
  role r? (r gt r?). So
• (?s ? S) r? ? authr(s) ? r gt r? ? r ? authr(s)

47
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
48
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 gt r
• Eredità di permessi (PI) Un ruolo r è
  autorizzato a tutti i permessi per i quali ogni
  ruolo r, tale che r gt r, è autorizzato
• Eredità di attivazione (AI) Attivando un ruolo r
  automaticamente si attivano tutti i ruoli r,
  tali che r gt r. Da usare solo con sessioni MRA

49
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

50
Separation of Duty

• Let r be a role, and let s be a subject such that
  r ? auth(s). Then the predicate meauth(r) (for
  mutually exclusive authorizations) is the set of
  roles that s cannot assume because of the
  separation of duty requirement.
• Separation of duty
• (?r1, r2 ? R) r2 ? meauth(r1) ?
• (?s ? S) r1? authr(s) ? r2 ? authr(s)
  

51
RBAC SoD statici

• SoD statici restringono linsieme 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

52
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 lutente 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

53
Key Points

• Hybrid policies deal with both confidentiality
  and integrity
• Different combinations of these
• ORCON model neither MAC nor DAC
• Actually, a combination
• RBAC model controls access based on functionality

54
Discussion