Gli appunti trattano i principi e le tecniche avanzate di protezione dei dati che possono essere utilizzate in scenari emergenti. Si affronteranno i concetti, le metodologie e le soluzioni scientifiche e tecnologiche relative alla protezione dei dati in scenari emergenti, permettendo di applicare in modo critico le conoscenze acquisite in svariati ambiti applicativi al fine di ottenere garanzia sulla protezione dei dati.
In questi appunti partendo dal controllo dell'accesso si procede verso lo studio delle basi di dati e ai metodi per poter effettuare interrogazione sulle tabelle che abbiamo salvato in modo sicuro in cloud. Infine negli ultimi modulo parleremo di differential privacy e di blockchain.
Anno accademico - 2018/2019 e 2019/2020
Complementi di
Sicurezza e Privatezza
Appunti di Maurizio Fortunati
Università degli Studi di Milano
Facoltà di Scienze e Tecnologie
Corso di Laurea Magistrale in Sicurezza informatica (Classe LM-66)
Esame di Complementi di Sicurezza e Privatezza
Docente: Sabrina De Capitani Di Vimercati
Anno accademico - 2018/2019 e 2019/2020Complementi di Sicurezza e
Privatezza
Appunti a cura di Maurizio Fortunati
Università degli Studi di Milano – Corso Magistrale in Sicurezza Informatica LM-66
Corso tenuto da Sabrina De Capitani di Vimercati
AA 2018/19
Sito Docente
Link Ariel - Lucidi
V2.0 – 21 feb. 2020
Sommario
Sommario .......................................................................................................... 2
Controllo dell'accesso ........................................................................................... 4
Primi approcci ................................................................................................. 4
Principi di progettazione di Saltzer e Schroeder ........................................................ 7
Politiche d’accesso ........................................................................................... 8
DAC ........................................................................................................... 9
MAC ......................................................................................................... 13
RBAC ........................................................................................................ 19
Administrative policies .................................................................................. 21
Clark and Wilson model for Integrity .................................................................... 21
Il modello .................................................................................................. 22
Regole ...................................................................................................... 23
Chinese Wall ................................................................................................. 24
Expanding authorizations .................................................................................. 25
Apache ..................................................................................................... 26
Logic based auth languages – FAF – da fare .......................................................... 26
Recent directions in access control ...................................................................... 26
Sistemi remoti ............................................................................................ 26
Basi di dati multilivello ........................................................................................ 27
OLS ............................................................................................................ 27
OpenStack Swift ................................................................................................ 28
Selective encryption ........................................................................................ 28
Policy-based encryption for OpenStack Swift ....................................................... 29
Over encryption ............................................................................................. 31
Integrità delle query ........................................................................................... 32
Metodi deterministici ...................................................................................... 32
Merkle hast tree .......................................................................................... 32
Skip list .................................................................................................... 34
Probabilistic Approaches ................................................................................... 36
Fake tuple ................................................................................................. 36
Computation with multiple providers ................................................................... 37
Dynamic encryption – “on the fly” .................................................................... 38
Markers .................................................................................................... 39
Twins ....................................................................................................... 39
Salts/Buckets ............................................................................................. 40
Distributed computational cloud – MapReduce ...................................................... 42
Query Distribuite ............................................................................................... 47
Sovereign join ............................................................................................... 48
Access patterns .............................................................................................. 48
View-Based authorizations ................................................................................ 49
Pairwise authorizations .................................................................................... 49
Distributed query evaluation under protection requirements ....................................... 50
Data Model ................................................................................................ 50
Permissions ................................................................................................ 51
Profilo della relazione ................................................................................... 52
Authorizations Composition ............................................................................... 52
Differential Privacy ............................................................................................. 54
Global Differential Privacy ................................................................................ 56
Algoritmo non trivial deterministico .................................................................. 56
Global sensitivity ............................................................................................ 56
Proprietà Global Differential Privacy ................................................................. 57
Local Differential Privacy .................................................................................. 57
Selezione cloud plan e preferenze utente .................................................................. 58
BROKERAGE-BASED APPROACH ............................................................................ 58
FUZZY-BASED REQUIREMENTS ............................................................................. 58
Blockchain ....................................................................................................... 60
Riferimenti ...................................................................................................... 63
Indice delle figure .......................................................................................... 63
Bibliografia ................................................................................................... 64
Controllo dell'accesso
Primi approcci
In questo capitolo vedremo le politiche, modelli e meccanismi del controllo dell’accesso.
Il controllo di accesso si occupa di valutare le richieste di accesso alle risorse da parte
dell’utente che è stato autenticato e in base ad alcune regole, determina se i diritti
d’accesso devono essere rilasciati o meno.
Il controllo si limita a verificare gli accessi diretti ma si può migliorare il controllo
effettuando un check su eventuali inferenze e flussi di informazioni.
La correttezza dell’accesso dipende dalla corretta identificazione del soggetto e dalla
correttezza delle grant che gli vengono affidate.
Quindi bisogna esser certi della correttezza delle informazioni sulle quali l’accesso viene
verificato.
Quindi:
La correttezza del controllo di accesso dipende da:
• Identificazione/autenticazione corretta
o Nessuno dovrebbe acquisire i privilegi di qualcun altro
o L’autenticazione oltre ad un discorso di sicurezza, serve anche per effettuare
Accountability
1
.
• Correttezza dell’autorizzazioni
o Rispetto alle quali l’accesso è valutato.
o Non deve esistere il concetto di account condiviso.
Studiando il controllo degli accessi è utile separare le Policy dai modelli e dai meccanismi.
Le policy, definiscono ad alto livello, le linee guida e le regole che gestiscono gli accessi da
autorizzare al sistema. Si può notare il contrasto tra closed e open policy.
Il modello, definisce formalmente le specifiche del controllo d’accesso
I meccanismi implementano le policy a basso livello e considerando le funzioni hardware e
software.
La separazione tra policy e meccanismi permette di poter implementare le policy in modo
indipendente rispetto ai requisiti di accesso e poter progettare meccanismi che riescono ad
implementare più policy.
A livello pratico il meccanismo che gestisce il controllo delle policy è il reference monitor.
Il reference monitor è di solito implementato come un modulo del kernel, e il suo compito è
quello di controllare tutti gli accessi software a oggetti o devices, decidendo quale processo
abbia i diritti o meno di poter accedere alla risorsa.
Il concetto di reference monitor deriva dagli scritti di James Anderson
2
del 1972.
1
Si potrebbe tradurre con rendicontazione ma accountability è formata dalle parole Account + Ability e
dalla sua etimologia si riesce a capirne il senso, si intende quello che viene effettuato da un account,
cioè l’abilità di poter associare/tracciare le attività di un account.
2
(Lewis, 2016)
Il concetto di reference monitor prevede che un componente del sistema, chiamato
“Reference validation mechanism”, sarà responsabile dell'applicazione della politica di
controllo degli accessi del sistema sulle operazioni dei processi dell'utente….”
Il concetto di reference monitor definisce i requisiti per l'implementazione di un meccanismo
in modo tale da garantire che gli utenti malintenzionati non possano eludere l'applicazione
delle policy. Il concetto di reference monitor non è solo responsabile di assicurare che i
riferimenti siano autorizzati ad accedere a oggetti di risorse condivise, ma anche di
assicurare che l’operazione sia del tipo giusto (ad esempio, read, read\write, ecc.).
Figura 1: Ref Mon - Kernel Vs User
In windows, vengono confrontati i token di accesso del processo assegnati dal DACL
(discretionary access control list) con I token presenti sull’oggetto che il processo vuole
accedere.
Vengono comparati i SID (Security IDentifier) dell’oggetto con quelli del soggetto e nel caso
in cui durante il confronto si genera un SID negato, l’accesso del processo all’oggetto viene
negato.
I SID sono degli identificativi univoci che vengono assegnati ad ogni processo, utente , gruppo
o qualsiasi Principal (entità)
3
.
3
Il principal o security principal in computer security è una qualsiasi entità che dispone di SID e che
può essere autenticata, può essere un thread di processi, un user o computer account.
I SID vengono salvati in un database e vengono gestite da active directory - (Microsoft, 2017)
Figura 2: Authorization and Acce ss control process
Grazie al Reference monitor si riescono ad effettuare i processi di auditing
4
per le policy
locali.
Un modulo, per esser utilizzato come reference monitor deve garantire alcune proprietà
spesso riferendosi con l’acronimo NEAT.
Non bypassable → il meccanismo di validazione deve mediare l’accesso al sistema e alle sue
risorse e non possono esser violate le policy di sicurezza da parte di un’attaccante
Evaluable → verificabile, ovvero è possibile fare dei test sul sistema per poterne verificare il
funzionamento e possa essere abbastanza semplice da poter subire un controllo tramite un
metodo di verifica formale.
Always invoked→ Il meccanismo di validazione deve essere sempre invocato, altrimenti è
possibile che un attaccante violare le policy di sicurezza.
Tamper proof → non può essere alternato da un’attaccante.
Nel materiale della docente, viene riportata una definizione leggermente diversa, viene
definito Tamper proof, e Non bypassable alla stessa maniera ma sdoppia il concetto di
Evaluable in Security Kernel e Small
Security kernel → il kernel del reference monitor è confinato in una parte limitata del
sistema e le funzioni di sicurezza diffuse in tutto il sistema implicano che il codice viene
verificato.
Small → il modulo deve essere piccolo abbastanza per poter subire una verifica formale.
4
Processo di valutazione delle policy
L’implementazione di un meccanismo non è semplice e deve far fronte a due problemi:
Storage Channel : gli elementi di memoria e porzioni di disco devono essere cancellate prima
di essere rilasciate per impedire la ricerca dei dati.
Covert channels: canali che non sono studiati per il passaggio di informazioni che vengono
sfruttati per farlo.
Quindi come si fa?
Principi di progettazione di Saltzer e Schroeder
Progettare un sistema sicuro è impossibile in quanto ci sarà sempre qualche difetto di
progettazione ma questi due signori, nel 1975
5
hanno definito alcuni principi che possono
essere utili per la progettazione e contribuire a un'implementazione senza difetti di
sicurezza.
Ecco otto esempi di principi di progettazione che si applicano in particolare ai meccanismi di
protezione.
1. Economia del meccanismo: mantieni il design il più semplice e piccolo possibile,
perché più è semplice meno errori ci sono e più facilmente si può condurre
un’ispezione line per linea del codice.
2. Impostazioni predefinite a prova di errore: di base tutti sono esclusi tranne quelli
permessi. Qusto metodo permette una maggiore sicurezza che definire chi è escluso.
Simile alle acl dove alla fine c’è un deny any – tutti esclusi tranne quelli che elenco
io.
3. Mediazione completa: ogni accesso a ogni oggetto deve essere verificato per
l'autorità. Forza una visione a livello di sistema del controllo degli accessi, che oltre
al normale funzionamento include l'inizializzazione, il ripristino, l'arresto e la
manutenzione. Implica che deve essere escogitato un metodo infallibile per
identificare la fonte di ogni richiesta.
4. Design aperto: il design non deve essere segreto. I meccanismi non dovrebbero
dipendere dall'ignoranza di potenziali aggressori, ma piuttosto dal possesso di chiavi o
password specifiche, più facilmente protette. Questo disaccoppiamento dei
meccanismi di protezione dalle chiavi di protezione consente ai meccanismi di essere
esaminati da molti revisori senza preoccuparsi che la revisione stessa possa
compromettere le garanzie. Inoltre, a qualsiasi utente scettico può essere permesso
di convincersi che il sistema che sta per usare è adeguato al suo scopo. Infine, non è
realistico tentare di mantenere il segreto per qualsiasi sistema che riceva ampia
distribuzione.
5. Separazione dei privilegi: ove possibile, un meccanismo di protezione che richiede
due chiavi per sbloccarlo è più robusto e flessibile di uno che consente l'accesso al
presentatore di una sola chiave.
6. Privilegio minimo: ogni programma e ogni utente del sistema dovrebbe operare
utilizzando il minor numero di privilegi necessari per completare il lavoro.
7. Meccanismo meno comune: ridurre al minimo la quantità di meccanismi comuni a più
di un utente e dipendente da tutti gli utenti. Ogni meccanismo condiviso (in
particolare uno che coinvolge variabili condivise) rappresenta un potenziale percorso
5
(SCHROEDER, 1975)
informativo tra gli utenti e deve essere progettato con grande cura per essere sicuro
che non comprometta involontariamente la sicurezza.
8. Accettabilità psicologica: è essenziale che l'interfaccia umana sia progettata per
facilità d'uso, in modo che gli utenti applichino regolarmente e automaticamente i
meccanismi di protezione correttamente.
Gli analisti dei sistemi di sicurezza fisica hanno suggerito altri due principi di progettazione
che, purtroppo, si applicano solo in modo imperfetto ai sistemi informatici.
9. Fattore di lavoro: confrontare il costo di aggirare il meccanismo con le risorse di un
potenziale attaccante.
10. Registrazione di compromesso: a volte viene suggerito che al posto di meccanismi più
elaborati che prevengono completamente la perdita si possano usare meccanismi che
registrano in modo affidabile che si è verificato un compromesso di informazioni. un
esempio, molti sistemi informatici registrano la data e l'ora dell'utilizzo più recente di
ciascun file. Se questo record è a prova di manomissione e segnalato al proprietario,
può aiutare a scoprire un utilizzo non autorizzato.
Come è evidente, questi principi non rappresentano regole assolute: servono come
avvertimenti.
Se una parte di un progetto viola un principio, la violazione è un sintomo di potenziale
problema e il progetto deve essere attentamente esaminato per essere sicuri che il problema
sia stato contabilizzato o che non sia importante.
L’approccio multifase dalle policy ai meccanismi passa attraverso la definizione di un
modello.
Il modello del controllo d’accesso deve essere completo e consistente.
Completo, che comprende tutti i requisiti di sicurezza che deve rappresentare.
Consistente, libero dalle contradizioni, cioè non può negare e garantire l’accesso allo stesso
tempo.
La definizione formale di un modello consente la prova delle proprietà sul sistema. Provando
che il modello sia formalmente sicuro e che i meccanismi siamo implementati correttamente,
si può dire che il sistema sia sicuro (secondo la definizione di sicuro).
Politiche d’accesso
intro
I sistemi di controllo dell’accesso si distinguono a seconda del tipo della politica che tali
sistemi supportano, e tali politiche si possono distinguere in politiche del controllo
dell’accesso e politiche amministrative.
Le politiche di controllo dell’accesso definiscono chi può o non può accedere alle risorse e in
generale è possibile dividere i modelli del controllo dell’accesso in discrezionali (DAC) e non.
La differenza tra i due è basata sull’entità di chi applica le policy.
In un DAC è il proprietario dell’oggetto che decide a chi concedere l’accesso, mentre nei
modelli non DAC è un ente centrale che decide al posto del proprietario.
Vedremo tre modelli
Discrezionali -Discretionary access control (DAC)
Mandatorie - Mandatory access control (MAC)
Basate sul ruolo – Role-based access control (RBAC)
Le politiche amministrative definiscono chi può concedere le autorizzazioni che regolano gli
accessi, vengono realizzate grazie al DAC e RBAC.
Figura 3: Panoramica dei modelli di controllo dell'accesso
Figura 4: pro e contro dei modelli
DAC
Nel modello DAC ogni risorsa ha un proprietario ben definito. Un utente che crea un file ne
diventa il proprietario e può decidere a propria DISCREZIONE a chi fornire i permessi per
accedere al file. Gli utenti si possono organizzare in gruppi e l’utente può rilasciare i
permessi al gruppo intero. Uno dei maggiori svantaggi del modello DAC è che le politiche di
sicurezza vengono affidate alla discrezione degli utenti.
Spesso si ci riferisce al modello HRU (Harrison, Ruzzo, Ullman) che definisce il modello di
sicurezza di un sistema, dove tramite la tripla (S,O,A) dove:
S è il soggetto, O è l’oggetto e A la matrice d’accesso che ha tante righe quanti sono i
soggetti e tante colonne quanti sono i file. Con A[s,o] si indicano i privilegi (azioni) del
soggetto s sull’oggetto o.
Figura 5: Esempio Access Matrix
La modifica avviene tramite comandi primitivi
• enter r into A[s, o]
• delete r from A[s, o]
• create subject s′
• destroy subject s′
• create object o ′
• destroy object o′
Le politiche amministrative possono esser attuate tramite l’associazione di opportuni flag ad
alcune azioni, ad esempio si può associare il flag (*) alla copia del privilegi e il flag (+) al loro
trasferimento
6
.
Copy flag (*): the subject can transfer the privilege to others
command TRANSFERread(subj,friend,file)
if Read* in A[subj,file]
then enter Read into A[friend,file] end.
Transfer-only flag (+): the subject can transfer to other the privilege (and the flag on it); but
so doing it loses the authorization.
command TRANSFER-ONLYread(subj,friend,file)
if Read+ in A[subj,file]
then delete Read+ from A[subj,file]
enter Read+ from A[friend,file] end.
L’esecuzione di un comando causa la transizione da uno stato di protezione Q ad un altro
stato di protezione Q’.
La flessibilità dei comandi amministrativi, come copy flag e trasnfer only flag, introduce il
problema della safety,
Il problema della safety si pone questo dubbio: è possibile che l'esecuzione di una sequenza
di comandi legittimi conduca il sistema in uno stato non lecito per le mie politiche?
6
Trasferire i privilegi indica che l’utente originario perde i propri privilegi a favore di un altro.
Cioè se partendo da uno stato di protezione Q è possibile eseguire una serie di richieste al
fine di far evolvere il sistema in uno stato Q’ dove l’azione A[s,o] che non era lecita in Q
diventi lecita (erroneamente) in Q’
Sì, è possibile, ma se non vengono fissate alcune limitazioni sui comandi, rilevare a priori
quale successione di comandi mi porti in uno stato in cui si violano le politiche si rivela un
problema non decidibile.
Lo si può rendere decidibile imponendo alcuni vincoli: i comandi devono essere mono-
operazionali (possono eseguire un'unica operazione primitiva), sia i soggetti che gli oggetti
devono essere in numero finito.
Data la quantità di soggetti e oggetti che caratterizzano un sistema, è facile immaginare
quanto una matrice degli accessi possa diventare vasta e memorizzarla come array
bidimensionale sarebbe un enorme spreco di spazio.
Utilizzando una matrice d’accesso, la maggior parte delle celle rimarrebbero vuote (non sono
definiti privilegi per ogni coppia di entità).
Le tecniche implementative più utilizzate sono dunque la tabella di autorizzazione, le Access
Control List e le Capability list.
• Authorization table: Memorizza tabella di triple non nulle (s, o, a). Generalmente
utilizzato nei DBMS ( Oracle, Mysql, MongoDB).
• ACL: Archivia per colonna, cioè per file
• Capability lists : Archivia per riga, cioè per utente
Auth Table
Le tabelle di autorizzazione memorizzano in una tabella a tre colonne tutte e solo quelle
triple (S,O,A) non vuote. Ad esempio:
Soggetto Azione Oggetto
Ann own File1
Bob read File1
Ann write File1
... ... ...
ACL
Nelle Access Control List (ACL) la memorizzazione avviene per colonne. Ogni riga rappresenta
una risorsa, poi avrò tante colonne quanti sono i soggetti che possono interagirvi, nelle cui
celle apparirà la lista dei loro permessi. Richiedono di autenticare i soggetti ad ogni richiesta
di accesso. Una possibile rappresentazione grafica è la seguente:
Figura 6: Esempio ACL
Capability List
Infine le Capability List (ticket) memorizzano per riga, ovvero ogni riga rappresenta un
utente con una lista di azioni consentite per i vari oggetti. Ad esempio:
Figura 7:Esempio Capability List
Differenze tra ACL e capability list:
Figura 8: ACL Vs capability list
Le ACL sono preferibili per quei sistemi in cui le operazioni sugli oggetti sono prevalenti, dal
momento che rendono particolarmente efficiente il controllo dell'accesso su tali entità.
Mentre sono meno efficienti per il controllo dei soggetti, in quanto per controllarli dovrei
infatti scandire tutti gli elementi della lista.
Le capability list al contrario hanno alte prestazioni nel controllo dell'accesso e nella
gestione dei soggetti, ma devono garantire la non falsificabilità della lista per garantire la
sicurezza, il che non è affatto semplice data la loro lunghezza.
Per questo motivo le capability list sono l'implementazione meno diffusa delle matrici
d'accesso.
Una debolezza delle politiche discrezionali è che sono in grado di poter verificare solamente
l’accesso diretto e il DAC non controlla a cosa accade alle info dopo che sono state rilasciate.
Un esempio è la debolezza ai trojan horse, l’utente estende i permessi al trojan horse, il
quale copia il contenuto del file che prima non poteva accedere e ricopia le informazioni in
un nuovo file accessibile ad altri.
Più di 40.000 tesi pubblicate:
leggi il riassunto, l'indice,
la preview;
puoi acquistare la
consultazione integrale.
Non sai da dove iniziare a
cercare?
- individua con precisione le
parole chiave;
- amplia la ricerca con termini
via via più generici;
- ti suggeriamo noi una lista di
argomenti tra cui cercare;
- scopri quali sono gli
argomenti più discussi nelle
tesi o quelli più ricercati.
Ti stai preparando per la tesi? Hai bisogno di materiali?
Appunti
universitari
Consultabili liberamente,
selezionati e pubblicati dalla
nostra redazione.
Divisi per ateneo, facoltà,
esame e argomento.
Puoi scaricarli gratuitamente.
Hai degli appunti interessanti?
Vendili a noi: li valutiamo e ti
paghiamo subito.
Scopri come »
Tesi di laurea
Come scrivere
una tesi di
laurea
I nostri consigli per
ottimizzare tempo e risorse.
Scarica la guida gratuita »
Ti senti perso?
Ecco i nostri consigli passo-
passo per iniziare.
Ascolta il podcast ed esegui i
compiti assegnati:
Podcast 1
Figura 9: Esempio trojan horse
MAC
Meccanismo attraverso il quale le decisioni di accesso sono basate su delle etichette che
contengono informazioni rilevanti circa la sicurezza di un oggetto.
Le politiche mandatorie impongono restrizioni sul flusso di informazioni e fanno distinzione
tra utenti e soggetti e considera gli utenti delle entità fidate mentre i soggetti (processi)
sono entità non fidate.
I sistemi DAC ignorano questa distinzione e quando vengono eseguiti i processi, vengono
tenute in considerazione l’identità dell’utente che esegue un determinato processo.
Gli utenti sono entità passive per cui sono definite autorizzazioni e possono collegarsi al
sistema dando luogo all’esecuzione dei soggetti (processi) che sottomettono delle richieste al
sistema.
Le politiche mandatorie realizzano il controllo dell’accesso in base a delle regole stabilite da
un‘ entità centrale, la politica più comune è quella multilivello con un ordinamento
parzialmente ordinato basato sulla classificazione di soggetti e oggetti.
Soggetti e oggetti creano una classe di sicurezza, composta da il livello di sicurezza e dalla
categoria.
Il livello di sicurezza sono elementi gerarchici che definiscono il livello di sicurezza, ad
esempio possono essere TopSecret(TS) > Secret(S) > Confidential(C) > Unclassified(U) mentre
le categorie sono un set di tag non gerarchici utilizzati per partizionare i dati, ad esempio,
finance, IT, HR, accounting.
Le due classi politiche più comuni sono
• Secrecy-based (e.g., Bell La Padula model)
7
• Integrity-based (e.g., Biba model)
7
(Rushby, 1986)
Il modello di Bell La Padula si concentra su riservatezza di dati e accesso a informazioni
classificate, in contrasto con il modello BIBA che descrive regole per la protezione dell’
integrità dei dati.
MAC - Bell La Padula
Lo scopo di questo modello è quello di garantire la sicurezza delle informazioni
(confidentiality) e viene garantita tramite un reticolo di sicurezza e la creazione di una
cleareance.
La clearance è la classe assegnata ad un utente, ed è il livello di autorizzazione dell'utente e
i settori su cui ha questa autorità.
Ogni utente ha un livello di segretezza a cui può accedere, ed un'area di competenza data
dalle categorie a cui può accedere.
Un utente può collegarsi al sistema utilizzando una qualsiasi classe che sia ≤ della sua
clearance. Per garantire la segretezza, vanno rispettate queste due proprietà:
La segretezza viene garantita impedendo flussi di informazione verso classi di accesso più
basse o non compatibili.
Ciò è assicurato da due proprietà vincolanti:
• no write down, il soggetto s può scrivere solo su oggetti o che hanno SC dominante: λ
(o) ≥ λ(s). Se è vero che da una parte ciò impedisce l'acquisizione di informazioni
riservate da parte di oggetti a cui ne è precluso l'accesso, dall'altra non garantisce
l'integrità delle informazioni.
• no read up, il soggetto s può leggere solo da oggetti o di SC inferiore: λ(s) ≥ λ(o).
Figura 10: BLP Information Flow
In questo modello esiste il concetto di stato sicuro, ovvero il sistema si effettua delle
transizioni da uno stato sicuro all’altro, uno stato è considerato sicuro se vengono rispettate
due proprietà, la simple security property e la *(start) property che sono il no read up e il no
write down.
La transizione T è l’insieme di richieste di accesso e T si può considerare sicura se e solo se
tutti i cambiamenti di stato in mezzo avvengano tra stati sicuri.
Successivamente bisogna verificare che lo stato di partenza domini lo stato di destinazione,
cioè bisogna considerare le categorie.