Problema dell'Inferenza
In questa sezione studiamo il problema dell'inferenza, cioè un modo di dedurre o derivare dati sensibili da dati non sensibili. Il problema dell'inferenza è una vulnerabilità sottile nella sicurezza dei DB. Il DB in tabella 1 può aiutare ad illustrare il problema dell'inferenza. Nel DB, AID è l'ammontare dell'aiuto finanziario che gli studenti ricevono. FINES è la quantità di multe di uno studente, DRUGS è un indicatore dell'uso di medicinali: 0 significa mai usati, 3 uso frequente. Ovviamente queste informazioni dovrebbero essere confidenziali. Assumiamo che AID, FINES e DRUGS sono campi sensibili, solo se i valori si riferiscono a singole persone. Vediamo ora le varie strategie d'attacco per determinare dati sensibili da questo DB.
| Name | Sex | Race | Aid | Fines | Drugs | Dorm |
|---|---|---|---|---|---|---|
| Adams | M | C | 5000 | 45. | 1 | Holmes |
| Bailey | M | B | 0 | 0. | 0 | Grey |
| Chin | F | A | 3000 | 20. | 0 | West |
| Dewitt | M | B | 1000 | 35. | 3 | Grey |
| Earhart | F | C | 2000 | 95. | 1 | Holmes |
| Fein | F | C | 1000 | 15. | 0 | West |
| Groff | M | C | 4000 | 0. | 3 | West |
| Hill | F | B | 5000 | 10. | 2 | Holmes |
| Koch | F | C | 0 | 0. | 1 | West |
| Liu | F | A | 0 | 10. | 2 | Grey |
| Majors | M | C | 2000 | 0. | 2 | Grey |
Attacco diretto
In un attacco si può tentare di determinare valori di campi sensibili cercandoli direttamente con query che producano pochi record. La tecnica più riuscita deve formulare una query così specifica che restituisce esattamente un item di dati. Nella tabella di sopra, una query sensibile sarebbe:
List NAME whereQuesta query svela che lo studente con nome ADAMS ha il valore del campo DRUGS=1. Tuttavia è un attacco ovvio poiché vi è un unico record restituito dalla query perciņ DRUGS=1. Una query meno ovvia è:
SEX=M AND DRUGS=1
List NAME whereA prima vista, questa query nasconde l'uso dei medicinali (DRUGS) selezionando altri campi che non si riferiscono ad esso. Essa recupera comunque un solo record, rivelando un nome che corrisponde al valore sensibile DRUGS. Il DBMS per riconoscere quest'attacco avrebbe bisogno di sapere che SEX può assumere solo due valori(M o F), accorgendosi che la seconda clausola non selezionerà nessun record. Anche se ciò fosse possibile, i DBMS avrebbero bisogno di sapere anche che in nessun archivio esiste il campo DORM con valore AYRES, anche se AYRES è un valore accettabile per questo campo. Organizzazioni che pubblicano statistiche personali non rivelano risultati in cui un numero piccolo di persone rappresenta una grande proporzione della categoria. La regola n item su k% significa che i dati dovrebbero essere riservati se n rappresentano un numero superiore al K% del risultato riportato. Nel caso precedente, una persona selezionata rappresenta il 100% dei dati riportati, in modo che non esiste nessuna ambiguità su quale persona corrisponde alla query.
(SEX=M AND DRUGS=1) OR
(SEX<>M AND SEX<>F) OR
(DORM=AYRES)
Attacco indiretto
Un'altra procedura usata dalle organizzazioni che raggruppano dati sensibili è quella di rilasciare soltanto statistiche. Sono eliminati nomi individuali, indirizzi o le altre caratteristiche dalle quali può essere riconosciuto un singolo individuo. Sono rilasciate statistiche neutrali, come somme, contatori e medie. L'attacco indiretto cerca di dedurre un risultato basato su uno o più risultati statistici. Questo tipo di attacco richiede calcoli al di fuori del DB. Un attacco statistico cerca di usare dati statistici apparentemente anonimi per dedurre dati individuali
Somma
Un attacco da somma tenta di dedurre risultati da una somma riportata. Per esempio, con il nostro DB sembrerebbe un'operazione sicura ottenere i valori del campo AID da quelli dei campi SEX e DORM. Tale operazione è mostrata in tabella 2. Questo risultato apparentemente innocente rivela che nessuno donna che vive a GREY riceve aiuto finanziario (AID). In questo modo ( dal valore 0 evidenziato in tabella) si deduce che qualsiasi donna che vive a GREY (come Liu) non riceve sicuramente aiuto finanziario. Questo è un altro esempio di rivelazione da un risultato negativo.
| Holmes | Grey | West | Total | |
|---|---|---|---|---|
| M | 5000 | 3000 | 4000 | 12000 |
| F | 7000 | 0 | 4000 | 11000 |
| Total | 12000 | 3000 | 8000 | 23000 |
Contatore
Un contatore può essere combinato con una somma per produrre altre
rivelazioni. Spesso queste due statistiche su un DB permettono agli
utenti di determinare valori medi (al contrario, se sono noti contatore
e media, la somma può essere dedotta).
La tabella 3 mostra il contatore dei record studenti
per i campi DORM e SEX. Questa tabella da sola è innocua. Combinata
con la tabella della somma, dimostra che due studenti maschi a HOLMES
e WEST ricevono aiuto finanziario nell'ammontare di $5000 e $4000 rispettivamente.
I nomi possono essere ottenuti selezionando il sottoschema di NAME e DORM,
che non è sensibile perché rilascia solamente dati di bassa
sicurezza sull'intero DB.
| Holmes | Grey | West | Totale | |
|---|---|---|---|---|
| M | 1 | 3 | 1 | 5 |
| F | 2 | 1 | 3 | 6 |
| Total | 3 | 4 | 4 | 11 |
Mediani
Attraverso un processo più complicato si può determinare un valore individuale dalle medie. L'attacco richiede la ricerca di selezioni che hanno un punto di intersezione, che cade precisamente nel mezzo, come mostrato in figura 2.1.
Figura 2.1 Intersezione Mediane
Per esempio, nel nostro DB ci sono cinque uomini e tre persone il cui valore di DRUGS è 2. Ordinate per campo AID, queste due liste sono mostrate in tabella 4. Si osservi che MAJORS è l'unico nome comune ad entrambe le liste ed esso è nel mezzo di ciascuna lista. Qualsiasi persona potrebbe scoprire che MAJORS è un maschio bianco il cui valore del campo DRUGS è 2. Ciò identifica MAJORS come l'intersezione di queste due liste, e indica l'aiuto finanziario (AID) di MAJORS in $2000. In questo esempio, le query
q=median(AID where SEX=M)rivelano l'esatto aiuto finanziario di MAJORS.
p=median(AID where DRUGS=2)
| Name | Sex | Drugs | Aid |
|---|---|---|---|
| Bailey | M | 0 | 0 |
| Dewitt | M | 3 | 1000 |
| Majors | M | 2 | 2000 |
| Groff | M | 3 | 4000 |
| Adams | M | 1 | 5000 |
| Liu | F | 2 | 0 |
| Majors | M | 2 | 2000 |
| Hill | F | 2 | 5000 |
Attacco del segugio
Come già spiegato, i DBMS possono celare dati in cui un numero piccolo di entry rivela una grande proporzione di dati. Un attacco del segugio può ingannare il DBMS localizzando i dati desiderati con l'utilizzo di query supplementari che producono come risultati un numero basso di record. Questo attacco aggiunge record supplementari che sono recuperati da due query diverse; le due collezioni di record si annullano a vicenda lasciando solamente la statistica desiderata. Invece di tentare di identificare un unico valore, richiede altri n-1 valori ( dove n sono i valori nel DB ). Dati n e n-1, si può calcolare facilmente il singolo elemento ricercato. Per esempio, si supponga di voler sapere quanti caucasici vivano in Holmes Hall. Una query potrebbe essere:
count ( (SEX=F) AND (RACE=C) AND (DORM=Holmes) )Il DBMS consulterà il DB scoprendo che la risposta è uno. Quindi si rifiuta di rispondere a questa query poiché vi è solo un record di risposta. Tuttavia, analisi ulteriori della query ci permettono di seguire le tracce di dati sensibili attraverso query di dati non sensibili. La query
q=count ( (SEX=F) AND (RACE=C) AND (DORM=Holmes) )è una query della forma q=count(a AND b AND c) Dall'algebra questa si può trasformare in
count(a) - count(a AND NOT(b AND c))Quindi, la query originale è equivalente a
count(SEX=F)sottratto
count((SEX=F) AND (RACE<>C) AND (DORM<>Holmes))Poiché count(a)=6 e count(a AND NOT(b AND c))=5, si può determinare il valore facilmente, 6-5=1. Né 6 né 5 sono contatori sensibili.
Vulnerabilità del sistema lineare
L'attacco precedente è un caso specifico di una vulnerabilità più generale. Con un pò di algebra e un pò più di fortuna nella distribuzione dei contenuti del DB, può essere possibile determinare una serie di query che ritornano risultati che riferiscono a molti insiemi differenti. Il sistema seguente di cinque query non rivela apertamente per esempio, qualsiasi singolo valore del DB. Tuttavia, le query (equazioni) possono essere risolte per ognuno dei c valori del DB, rivelandoli tutti.
q1=c1+c2+c3+c4+c5Dall'algebra q1-q2=c3+c5, q3-q4=c3-c5. Quindi sottraendo queste due equazioni, si ottiene c5=((q1-q2)-(q3-q4))/2. Gli altri valori possono essere in seguito ottenuti da c5. Questo attacco può anche essere usato per ottenere risultati oltre che da attacchi statistici. Si noti che le stesse proprietà dell'algebra ricorrono con AND e OR, che sono operatori tipici per query di un DB. Per esempio, ogni query potrebbe chiedere dati precisi, invece di contatori, con una richiesta della forma
q2=c1+c2 +c4
q3= +c3+c4
q4= +c4+c5
q5= +c2 +c5
q1=s1 OR s2 OR s3 OR s4 OR s5Il risultato è un insieme di record che soddisfano la query. Dall'algebra degli insiemi possono essere ottenuti risultati singoli risolvendo il sistema di equazioni di insiemi lineari analogamente alle query numeriche viste in precedenza.
Controlli su attacchi statistici di inferenza
I controlli per tutti gli attacchi statistici sono identici. Denning e Schlorer hanno presentato un buon insieme di tecniche per mantenere la sicurezza nei DB. Ci sono essenzialmente due modi per proteggersi contro attacchi di inferenza. I controlli sono applicati alle query oppure ai singoli item all'interno del DB. Come si è visto, è difficile determinare se una query rivela dati sensibili. Di certo, i controlli sulle query sono efficaci in primo luogo contro attacchi diretti. Due controlli applicati a item di dati sono la soppressione e l'occultamento. Con la soppressione i dati sensibili non sono forniti, la query è negata senza risposta. Con l'occultamento la risposta fornita è simile ma non è esattamente il valore attuale. Questi due controlli riflettono il contrasto tra sicurezza e precisione. Con la soppressione, qualsiasi risultato fornito è corretto, sebbene molte risposte non sono fornite per mantenere la sicurezza. Con l'occultamento possono essere forniti più dati, sebbene la loro accuratezza è molto bassa. La scelta tra soppressione e occultamento dipende dal contesto del DB. Seguono esempi di questi due controlli.
Soppressione a risposta limitata
La regola n item K% elimina certi elementi di bassa frequenza da quelli forniti. Tuttavia, non è sufficiente cancellarli se i loro valori possono essere anche dedotti. Si consideri la tabella 5 che mostra i contatori di studenti per i campi DORM e SEX. Con questa tabella, le celle con contatori a 1 dovrebbero essere soppresse poiché i loro contatori sono troppo rivelatori. Ma non è bene sopprimere la cella Male-Holmes quando il valore 1 può essere determinato sottraendo Female-Holmes (2) dal totale (3) per ottenere 1, come mostrato in tabella 6. Quando una cella è soppressa in una tabella con totali per righe e per colonne, è necessario sopprimere almeno una cella in più nelle righe e una nelle colonne per creare un pò di confusione. Da questa logica, tutte le celle (eccetto i totali) dovrebbero essere soppresse in questa piccola tabella di esempio. Quando non sono forniti totali, celle singole nelle righe o nelle colonne possono essere soppresse.
| Holmes | Grey | West | Totale | |
|---|---|---|---|---|
| M | 1 | 3 | 1 | 5 |
| F | 2 | 1 | 3 | 6 |
| Total | 3 | 4 | 4 | 11 |
| Holmes | Grey | West | Totale | |
|---|---|---|---|---|
| M | - | 3 | - | 5 |
| F | 2 | - | 3 | 6 |
| Total | 3 | 4 | 4 | 11 |
Combinazioni di risultati
Un altro controllo combina righe e colonne per proteggere valori sensibili. Per esempio, la tabella 7 mostra molti risultati sensibili che identificano singoli individui (anche se questi contatori possono sembrare non sensibili, possono essere usati per dedurre dati sensibili come i valori del campo NAME e quindi sono considerati sensibili). Questi contatori, combinati con altri valori come le somme, permettono sia di dedurre i valori singoli di DRUGS per tre uomini, sia dedurre che nessuna donna ha 3 come valore di DRUGS. Per sopprimere queste informazioni sensibili, è possibile combinare i valori di attributi per 0 e 1, e per 2 e 3, producendo il risultato meno sensibile mostrato in tabella 8. In questa istanza di tabella è impossibile identificare qualsiasi valore singolo. Un altro modo di combinare risultati è presentare i valori in range. Invece di rivelare i valori esatti di aiuto finanziario, i risultati possono essere rilasciati come range $0-1999, $2000-3999, o $4000 e superiore. Anche se vi è un solo record che rappresenta un singolo risultato non si conosce il valore esatto di quel record. Nello stesso modo si possono tenere nascosti gli aiuti finanziari più alti e più bassi. Un ulteriore metodo che combina i risultati è l'arrotondamento. Questo è un esempio abbastanza conosciuto di combinazione utilizzando il metodo dei range. Se i numeri sono arrotondati alla decina più vicina, gli effettivi range sono 0-5, 6-15, 16-25. I valori attuali sono arrotondati per eccesso o per difetto al più vicino multiplo della rispettiva base.
| Drug Use | ||||
|---|---|---|---|---|
| Sex | 0 | 1 | 3 | 3 |
| M | 1 | 1 | 1 | 2 |
| F | 2 | 2 | 2 | 0 |
| Drug Use | ||
|---|---|---|
| Sex | 0 or 1 | 2 or 3 |
| M | 2 | 3 |
| F | 4 | 2 |
Esemplare casuale
Con il controllo dell'esemplare casuale, un risultato non è dedotto dall'intero DB, ma č derivato da un esemplare casuale del DB. L'esemplare scelto deve essere ampio abbastanza per essere valido. Tuttavia, poiché l'esemplare non è l'intero DB, una query su questo esemplare non darà necessariamente risultati che lo rappresentino. Per prevenire attacchi di media da query equivalenti, dovrebbe essere scelto lo stesso insieme esemplare per query equivalenti. In questo modo, tutte le query equivalenti produrranno lo stesso risultato, sebbene questo risultato sarà solo un'approssimazione dell'intero DB.
Disturbo casuale dei dati
Un altro controllo statistico è disturbare i valori di un DB con piccoli errori. Se xi è un valore corretto dell'item i del DB, ei è un piccolo errore casuale aggiunto a xi per risultati statistici. Il valore e è sia positivo che negativo, in modo che i valori restituiti possono essere sia più alti sia più bassi del valore corretto. Misure statistiche come somme e medie saranno simili, ma non necessariamente esatte. Il disturbo di dati è più facile da usare dell'esemplare casuale poiché è più facile tenere tutti i valori e per produrre lo stesso risultato per query equivalenti.
Analisi di query
Una forma più complessa di sicurezza usa l'analisi delle query. Una query e le sue implicazioni sono analizzate per determinare se il risultato può essere fornito o no. L'analisi delle query può essere molto difficoltosa. Un approccio implica di mantenere una storia delle query per ogni utente e giudicare una query nel contesto di quali deduzioni sono possibili dati i risultati delle query precedenti.
Conclusioni sul problema dell'inferenza
Non esistono soluzioni perfette per il problema dell'inferenza. Gli approcci per controllarlo seguono tre strade. I primi due metodi possono essere usati per limitare le query accettate o per limitare i dati forniti in risposta ad una query. L'ultimo metodo è applicata solo su dati rilasciati.
- Sopprimere ovvie informazioni sensibili. Ciò può essere
abbastanza facile da fare. Vi è però una tendenza a voler
sopprimere troppo, restringendo l'utilità del DB.
- Tenere traccia di ciò che l'utente conosce. Sebbene questo
metodo è uno tra i migliori, è estremamente costoso. Devono
essere tenute informazioni per tutti gli utenti, anche se la maggior parte
non tenta di ottenere informazioni sensibili. Questo approccio raramente
tiene in considerazione ciò che due utenti conoscono unendo le proprie
informazioni.
- Travestire i dati. Disturbi e arrotondamenti casuali possono inibire
attacchi statistici che dipendono dai valori esatti per le manipolazioni
algebriche. Gli utenti del DB però possono ricevere dati
leggermente scorretti, o peggio, inconsistenti.
 |
 |
 |
DIA - Dipartimento
di
Informatica ed Applicazioni |
 |