diff --git a/magistrale/Anno 1/Cybersecurity/Appunti_Cybersecurity-Bistarelli.pdf b/magistrale/Anno 1/Cybersecurity/Appunti_Cybersecurity-Bistarelli.pdf index ffdbd06aa..a62b0d7b9 100644 Binary files a/magistrale/Anno 1/Cybersecurity/Appunti_Cybersecurity-Bistarelli.pdf and b/magistrale/Anno 1/Cybersecurity/Appunti_Cybersecurity-Bistarelli.pdf differ diff --git a/magistrale/Anno 1/Cybersecurity/latex/.devcontainer/Dockerfile b/magistrale/Anno 1/Cybersecurity/latex/.devcontainer/Dockerfile index a43b91816..022f3896f 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/.devcontainer/Dockerfile +++ b/magistrale/Anno 1/Cybersecurity/latex/.devcontainer/Dockerfile @@ -4,7 +4,11 @@ FROM qmcgaw/latexdevcontainer RUN tlmgr update --self # installo pacchetti necessari -RUN tlmgr install listings caption xcolor float wrapfig footmisc emoji fontspec emptypage && texhash +RUN tlmgr install \ + listings caption xcolor float wrapfig \ + footmisc emoji fontspec emptypage pgf \ + babel-italian etoolbox \ + && texhash # installo font emoji RUN apt install fonts-noto-color-emoji \ No newline at end of file diff --git a/magistrale/Anno 1/Cybersecurity/latex/.gitignore b/magistrale/Anno 1/Cybersecurity/latex/.gitignore index 8d5ebad76..a96f3d296 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/.gitignore +++ b/magistrale/Anno 1/Cybersecurity/latex/.gitignore @@ -1,3 +1,279 @@ -*.pdf -*.synctex.gz +## Core latex/pdflatex auxiliary files: +*.aux +*.lof *.log +*.lot +*.fls +*.out +*.toc +*.fmt +*.fot +*.cb +*.cb2 +.*.lb + +## Intermediate documents: +*.dvi +*.xdv +*-converted-to.* +# these rules might exclude image files for figures etc. +# *.ps +# *.eps +# *.pdf + +## Generated if empty string is given at "Please type another file name for output:" +main.pdf + +## Bibliography auxiliary files (bibtex/biblatex/biber): +*.bbl +*.bcf +*.blg +*-blx.aux +*-blx.bib +*.run.xml + +## Build tool auxiliary files: +*.fdb_latexmk +*.synctex +*.synctex(busy) +*.synctex.gz +*.synctex.gz(busy) +*.pdfsync + +## Build tool directories for auxiliary files +# latexrun +latex.out/ + +## Auxiliary and intermediate files from other packages: +# algorithms +*.alg +*.loa + +# achemso +acs-*.bib + +# amsthm +*.thm + +# beamer +*.nav +*.pre +*.snm +*.vrb + +# changes +*.soc + +# comment +*.cut + +# cprotect +*.cpt + +# elsarticle (documentclass of Elsevier journals) +*.spl + +# endnotes +*.ent + +# fixme +*.lox + +# feynmf/feynmp +*.mf +*.mp +*.t[1-9] +*.t[1-9][0-9] +*.tfm + +#(r)(e)ledmac/(r)(e)ledpar +*.end +*.?end +*.[1-9] +*.[1-9][0-9] +*.[1-9][0-9][0-9] +*.[1-9]R +*.[1-9][0-9]R +*.[1-9][0-9][0-9]R +*.eledsec[1-9] +*.eledsec[1-9]R +*.eledsec[1-9][0-9] +*.eledsec[1-9][0-9]R +*.eledsec[1-9][0-9][0-9] +*.eledsec[1-9][0-9][0-9]R + +# glossaries +*.acn +*.acr +*.glg +*.glo +*.gls +*.glsdefs +*.lzo +*.lzs + +# uncomment this for glossaries-extra (will ignore makeindex's style files!) +# *.ist + +# gnuplottex +*-gnuplottex-* + +# gregoriotex +*.gaux +*.gtex + +# htlatex +*.4ct +*.4tc +*.idv +*.lg +*.trc +*.xref + +# hyperref +*.brf + +# knitr +*-concordance.tex +# TODO Comment the next line if you want to keep your tikz graphics files +*.tikz +*-tikzDictionary + +# listings +*.lol + +# luatexja-ruby +*.ltjruby + +# makeidx +*.idx +*.ilg +*.ind + +# minitoc +*.maf +*.mlf +*.mlt +*.mtc[0-9]* +*.slf[0-9]* +*.slt[0-9]* +*.stc[0-9]* + +# minted +_minted* +*.pyg + +# morewrites +*.mw + +# nomencl +*.nlg +*.nlo +*.nls + +# pax +*.pax + +# pdfpcnotes +*.pdfpc + +# sagetex +*.sagetex.sage +*.sagetex.py +*.sagetex.scmd + +# scrwfile +*.wrt + +# sympy +*.sout +*.sympy +sympy-plots-for-*.tex/ + +# pdfcomment +*.upa +*.upb + +# pythontex +*.pytxcode +pythontex-files-*/ + +# tcolorbox +*.listing + +# thmtools +*.loe + +# TikZ & PGF +*.dpth +*.md5 +*.auxlock + +# todonotes +*.tdo + +# vhistory +*.hst +*.ver + +# easy-todo +*.lod + +# xcolor +*.xcp + +# xmpincl +*.xmpi + +# xindy +*.xdy + +# xypic precompiled matrices and outlines +*.xyc +*.xyd + +# endfloat +*.ttt +*.fff + +# Latexian +TSWLatexianTemp* + +## Editors: +# WinEdt +*.bak +*.sav + +# Texpad +.texpadtmp + +# LyX +*.lyx~ + +# Kile +*.backup + +# gummi +.*.swp + +# KBibTeX +*~[0-9]* + +# TeXnicCenter +*.tps + +# auto folder when using emacs and auctex +./auto/* +*.el + +# expex forward references with \gathertags +*-tags.tex + +# standalone packages +*.sta + +# Makeindex log files +*.lpz + +#vscode settings +.vscode/ \ No newline at end of file diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/autenticazione/intruders.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/autenticazione/intruders.tex index 96183a7a2..7df476559 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/autenticazione/intruders.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/autenticazione/intruders.tex @@ -3,65 +3,35 @@ \section{Intruder} Abbiamo tre classi di intruders (intrusi): \begin{itemize} - \item \textbf{Masquerader}: Un individuo che non è autorizzato a utilizzare il - computer e che penetra nei - controlli di accesso di un sistema per sfruttare l'account di un utente - legittimo; - \item \textbf{Misfeasor}\footnote{Ricordarsi che non è - il nome di un pokemon !}: Un utente legittimo che accede a dati, - programmi o - risorse per i - quali tale - accesso non è autorizzato o che è autorizzato a tale accesso ma - abusa dei suoi - privilegi; - \item \textbf{Clandestine User}: Una persona che prende il controllo di supervisione - per eludere l'auditing - e i controlli di accesso o sopprimere la raccolta di audit; + \item \textbf{Masquerader}: Individuo che finge di essere qualcun altro per ottenere un accesso non autorizzato a informazioni o servizi. + \item \textbf{Misfeasor}\footnote{Ricordarsi che non è il nome di un pokemon !}: Un utente legittimo che accede a dati, programmi o risorse per i quali tale accesso non è autorizzato o che è autorizzato a tale accesso ma abusa dei suoi privilegi per eseguire azioni non autorizzate. Un esempio può essere il dipendente con accesso a dati aziendali sensibili che utilizza i propri privilegi per rubare o divulgare i dati; + \item \textbf{Clandestine User}: Una persona che prende il controllo di supervisione per eludere l'auditing e i controlli di accesso o sopprimere la raccolta di audit; \end{itemize} \paragraph{Intrusion Detection System: } -L'Intrusion Detection System o \textbf{IDS} è un dispositivo software o hardware -utilizzato per -identificare accessi non autorizzati ai computer o alle reti locali. -Le intrusioni rilevate possono -essere quelle prodotte da cracker esperti, da tool automatici o da utenti -inesperti che utilizzano -programmi semiautomatici. +L'Intrusion Detection System o \textbf{IDS} è un dispositivo software o hardware utilizzato per identificare accessi non autorizzati ai computer o alle reti locali. Lo scopo generale di un IDS è informare gli amministratori di sistema che potrebbe esserci un'intrusione nel sistema. Lo fa andando a lanciare degli allarmi che poi gli amministratori di sistema dovranno andare a controllare manualmente. Gli avvisi includono generalmente informazioni sull'indirizzo di origine dell'intrusione, l'indirizzo di +destinazione/vittima e il tipo di attacco ``sospetto''. + +Un IDS può avere un'installazione o di tipo \textbf{HOST based} o di tipo \textbf{NETWORK based}. Nella \emph{Host based} l'IDS è installato nelle singole macchine utente ed ha quindi una vista ristretta alla singola macchina e non all'intero sistema. In questo caso lavora più a \emph{livello applicazione} per rilevare le intrusioni. Nel \emph{Network based} invece l'IDS è installato a livello di rete e quindi ha una visione più ampia e generale del sistema. In questo caso lavora appunto a livello di rete e quindi riesce a rilevare se un nuovo dispositivo si collega alla rete o se un dispositivo invia strane richieste. + +Un IDS può individuare una intrusione tramite 3 tipologie di rilevamento differenti: +\begin{itemize} + \item \textbf{Threshold based detection}: si conta il numero di occorrenze di un determinato evento e se tale numero supera una determinata soglia allora viene considerato come ``attacco in corso''. E' una tecnica di rilevamento basata su anomalie (\emph{anomaly detection}). + \item \textbf{Profile based detection}: si traccia ciò che un account fa abitualmente e si guarda se in una giornata sta assumendo il solito comportamento o se si discosta molto dalle abitudini. Se si discosta troppo allora si considera come ``attacco in corso''. E' una tecnica di rilevamento basata su anomalie (\emph{anomaly detection}). + \item \textbf{Signature based detection}: si usano modelli di attacchi già noti e si mette a confronto il comportamento rilevato con i modelli conosciuti per vedere se corrispondono a una minaccia nota. +\end{itemize} + +È importante sapere che un IDS non può bloccare o filtrare i pacchetti in ingresso ed in uscita, né tanto meno può modificarli. Un IDS può essere paragonato ad un antifurto mentre il firewall alla porta blindata. L'IDS non cerca di bloccare le eventuali intrusioni, cosa che spetta al firewall, ma cerca di rilevarle laddove si verifichino. +Per ogni rete è necessario un IDS che agisce solo sulla stessa. + +\paragraph{Intrusion Prevenction System}: L'Intrusion Prevenction System o \textbf{IPS} è un dispositivo software o hardware che ha le stesse funzionalità di un IDS ma in più può fermare un attacco in \textbf{real time} andando a compiere alcune azioni quali comunicare con un firewall e aggiungere delle regole per bloccare determinate connessioni malevole o mandare down l'intero network (solo nei casi peggiori) così da evitare ulteriori danni al sistema. -Lo scopo generale di un IDS è informare che potrebbe esserci un'intrusione nella rete. -Gli avvisi -includono generalmente informazioni sull'indirizzo di origine dell'intrusione, -l'indirizzo di -destinazione/vittima e il tipo di attacco "sospetto”. -Due sono le categorie base: sistemi basati sulle firme (signature) e sistemi -basati sulle anomalie (anomaly). -La tecnica basata sulle firme è in qualche modo analoga a quella per -il rilevamento dei -virus (adopera il machine learning), essa permette di bloccare file infetti e -si tratta di una tra le tecniche più utilizzate. I sistemi basati sul rilevamento delle anomalie utilizzano un -insieme di regole che -permettono di distinguere ciò che è "normale" da ciò che è "anormale". -È importante sapere che un IDS non può bloccare o filtrare i pacchetti in ingresso -ed in uscita, né -tanto meno può modificarli. Un IDS può essere paragonato ad un antifurto mentre -il firewall alla -porta blindata. L'IDS non cerca di bloccare le eventuali intrusioni, cosa che -spetta al firewall, ma -cerca di rilevarle laddove si verifichino. -Per ogni rete è necessario un IDS che agisce solo sulla stessa. Se si volesse -però avere -un'architettura più complessa, si potrebbe includere un gestore centrale: -gli IDS fanno da sensore, -inviano tutto c'è che rilevano nella rete di pertinenza al gestore, -il quale accumula ed analizza tutti i -log ricevuti per capire se gli eventi hanno una qualche correlazione. \paragraph{Honeypot {\normalfont \emoji{honey-pot}}:} Un honeypot rappresenta una strategica misura di sicurezza con la quale gli amministratori di un server ingannano gli hacker e gli impediscono di colpire. -Un “barattolo di miele” simula i +Un ``barattolo di miele'' simula i servizi di rete o programmi per attirare i malintenzionati e proteggere il sistema da eventuali attacchi. In pratica gli utenti configurano gli honeypot, utilizzando delle diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/autenticazione/kerberos.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/autenticazione/kerberos.tex index 22d014f87..40c1e41c5 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/autenticazione/kerberos.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/autenticazione/kerberos.tex @@ -3,27 +3,27 @@ \section{Kerberos} In un sistema si può aggiungere una procedura di autenticazione per ogni servizio, ad esempio una password per accedere al sistema, una per accedere al file system, ecc. Questa tecnica risulta essere molto scomoda, soprattutto se si utilizzano -i token. Un’alternativa consiste nell’utilizzare un’unica credenziale di -autenticazione per accedere a tutti i servizi; avere un’unica password è una +i token. Un'alternativa consiste nell'utilizzare un'unica credenziale di +autenticazione per accedere a tutti i servizi; avere un'unica password è una soluzione comoda ma poco robusta. Kerberos è un \textbf{protocollo} reale che si occupa di questo problema (e non solo), -ha come obiettivo quello di garantire la segretezza, l’autenticità +ha come obiettivo quello di garantire la segretezza, l'autenticità (ad accesso singolo), la temporalità (le chiavi usate hanno validità limitata per prevenire \textit{replay attack}). -Quest’ultima caratteristica viene gestita tramite -i \textbf{timestamp}. In pratica, l’accesso ad un servizio avviene tramite -“biglietto” che vale per un periodo limitato; anche se tale biglietto venisse +Quest'ultima caratteristica viene gestita tramite +i \textbf{timestamp}. In pratica, l'accesso ad un servizio avviene tramite +``biglietto'' che vale per un periodo limitato; anche se tale biglietto venisse intercettato, può essere usato solo una volta e per un breve tempo. \paragraph{Kerberos} è un protocollo di autenticazione dei servizi di rete creato dal MIT che si serve della crittografia a chiave simmetrica per autenticare gli utenti per i servizi di rete, eliminando così la necessità di inviare le password attraverso -la rete. Ricorre ad un’unica credenziale di autenticazione per accedere a tutti +la rete. Ricorre ad un'unica credenziale di autenticazione per accedere a tutti i servizi. L'autenticazione mediante Kerberos impedisce agli utenti non autorizzati di intercettare le password inviate attraverso la rete. Il nome Kerberos deriva da Cerbero, il cane a tre teste che sorveglia -le porte dell’Ade.\\ +le porte dell'Ade.\\ La maggior parte dei sistemi di rete convenzionali usa uno schema di autenticazione basato sulle password. Quando un utente effettua una @@ -49,9 +49,9 @@ \section{Kerberos} \subsection{Come funziona ?} -L’utente, una volta entrato nella propria macchina, vuole accedere ai servizi +L'utente, una volta entrato nella propria macchina, vuole accedere ai servizi messi a disposizione nella rete. Supponiamo voglia raggiungere il server in basso. -Effettuato il primo accesso alla macchina, le credenziali dell’utente vengono +Effettuato il primo accesso alla macchina, le credenziali dell'utente vengono inviate ad uno speciale servizio centrale, il Kerberos, che ricorre essenzialmente a due tipi di server: @@ -59,8 +59,8 @@ \subsection{Come funziona ?} \item \textit{Authentication Server} (\textbf{AS}\footnote{Ricordarsi che AS non sta per \textit{Autonomous System} !}), - che ha lo scopo di autenticare l’user; - \item \textit{Ticket-Granting Server} (\textbf{TGS}), che a seconda dell’user, + che ha lo scopo di autenticare l'user; + \item \textit{Ticket-Granting Server} (\textbf{TGS}), che a seconda dell'user, gli assegna i diritti per compiere determinate azioni; \end{itemize} @@ -71,15 +71,15 @@ \subsection{Come funziona ?} \end{figure} \begin{enumerate} - \item L’utente si connette con le proprie credenziali alla workstation e + \item L'utente si connette con le proprie credenziali alla workstation e queste vengono passate al Kerberos; - \item AS verifica il diritto di accesso dell’utente, ricercando una + \item AS verifica il diritto di accesso dell'utente, ricercando una corrispondenza nel database. Se il confronto ha esito positivo, AS - assegna all’user un ticket e una session key. + assegna all'user un ticket e una session key. Il ticket verrà poi passato al TGS per richiedere i servizi, mentre la chiave permette di codificare le sue richieste, sempre poste al TGS. Entrambe le informazioni vengono criptate; - \item L’utente a questo punto vuole utilizzare un certo servizio. + \item L'utente a questo punto vuole utilizzare un certo servizio. La workstation richiede all'utente la password e la utilizza per decrittografare il messaggio in arrivo, quindi invia ticket e autenticatore @@ -90,12 +90,12 @@ \subsection{Come funziona ?} TGS avviene solo grazie alla session key che la codifica; \item La workstation manda ticket e autenticatore al server; \item Il server verifica il match tra ticket ed autenticatore e permette - l’accesso al servizio. Se + l'accesso al servizio. Se viene richiesta una mutua autenticazione, il server ritorna un autenticatore. \end{enumerate} -È importante notare che l’utente può utilizzare il ticket finché esso risulta +È importante notare che l'utente può utilizzare il ticket finché esso risulta ancora valido, il che può accadere anche per più tentativi di richiesta al servizio. Per un servizio diverso mai utilizzato, deve ripercorrere il medesimo processo.\\ @@ -108,11 +108,11 @@ \subsection{Come funziona ?} \end{figure} \begin{enumerate} - \item All’autenticazione si ottiene \verb|authK| e \verb|authTicket|. + \item All'autenticazione si ottiene \verb|authK| e \verb|authTicket|. Il primo per autenticarsi e rendere riservata la trasmissione con il TGS, il secondo per ottenere il servizio del TGS; - \item Nell’autorizzazione da parte del TGS, si ottiene \verb|servK| e + \item Nell'autorizzazione da parte del TGS, si ottiene \verb|servK| e \verb|servTicket|, da presentare per il server richiesto; \item Il servizio conferma poi la richiesta. @@ -126,16 +126,16 @@ \subsection{Come funziona ?} \subsection{Nel dettaglio} -\textit{A} è l’utente che richiede il servizio \textit{B}. -\textit{A} si autentica all’AS ad un certo tempo \verb|T1| -(\textit{messaggio 1}). Se l’utente non è registrato tra quelli del dominio, +\textit{A} è l'utente che richiede il servizio \textit{B}. +\textit{A} si autentica all'AS ad un certo tempo \verb|T1| +(\textit{messaggio 1}). Se l'utente non è registrato tra quelli del dominio, non viene preso in considerazione. Se invece è autorizzato, si verifica grazie al ticket a quale TGS vuole rivolgersi. -\textit{A} per autenticarsi ha inviato solo il nome dell’utente, però l’AS fa -una challenge: invia ad \textit{A} un’informazione e se l’utente è +\textit{A} per autenticarsi ha inviato solo il nome dell'utente, però l'AS fa +una challenge: invia ad \textit{A} un'informazione e se l'utente è effettivamente chi dice di essere, allora saprà decifrarla con la sua chiave. \textit{A} apre il pacchetto con la chiave privata (\textit{messaggio 2}). -All’interno trova: +All'interno trova: \begin{itemize} \item un \verb|authTicket| codificato con la chiave di TGS e quindi non può @@ -150,8 +150,8 @@ \subsection{Nel dettaglio} All'interno del \textit{messaggio 3} abbiamo: \begin{itemize} - \item ticket ricevuto dall'AS, anche se non sa cos’è; - \item il suo nome e \verb|T2| che corrisponde all’istante in cui viene + \item ticket ricevuto dall'AS, anche se non sa cos'è; + \item il suo nome e \verb|T2| che corrisponde all'istante in cui viene inviato il pacchetto. Il tutto è codificato da \verb|authK|; \item nome del servizio a cui vuole accedere, cioè \textit{B}; @@ -159,15 +159,15 @@ \subsection{Nel dettaglio} Il fatto di inviare \textit{A} e \verb|authK| permette di autenticarsi con il TGS. \verb|authK| è stata inviata da AS e poiché TGS si fida di AS, riesco ad aprire -il messaggio \verb|{A, T2}| dell’autenticatore 1. Il messaggio è chiaramente +il messaggio \verb|{A, T2}| dell'autenticatore 1. Il messaggio è chiaramente scritto da \textit{A} e la conferma arriva dal fatto che \textit{A} è scritto -anche fuori in \verb|authTicket| e l’\verb|authK| è stato condiviso da AS +anche fuori in \verb|authTicket| e l'\verb|authK| è stato condiviso da AS con \textit{A}. A questo punto \textit{A} è autenticato. Se il \textit{messaggio 3} fosse stato inviato al TGS sbagliato, al richiesta non verrebbe presa in considerazione. \verb|Ta| permette di capire se \verb|authK| è ancora valida. Il TGS verifica se \textit{A} ha il diritto di utilizzare \textit{B}. Se così è, -viene autorizzato con l’invio del \textit{messaggio 4}: +viene autorizzato con l'invio del \textit{messaggio 4}: \begin{itemize} \item È criptato con \verb|authK| e solo \textit{A} può aprirlo. @@ -225,7 +225,7 @@ \subsection{Gestione delle Chiavi} \end{itemize} TGS può generare \verb|servK| solo qualora sia \(Ts + L_s \le Ta + L_a\), -altrimenti si verifica il problema di \textbf{cascata dell’attacco}. Si hanno +altrimenti si verifica il problema di \textbf{cascata dell'attacco}. Si hanno quindi attacchi consequenziali: un attacco ne provoca altri direttamente. Supponiamo che \textit{C} abbia violato una chiave di sessione (di autorizzazione) scaduta \verb|authK| che \textit{B} aveva condiviso con \textit{A}. diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/autenticazione/tipi.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/autenticazione/tipi.tex index d74c8e81e..0097b1710 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/autenticazione/tipi.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/autenticazione/tipi.tex @@ -30,7 +30,7 @@ \section{Tipi di Autenticazione} da quella dove è avvenuto il collegamento; sul server digitando le proprie credenziali (per aprire file, fare login..); - \item \textbf{Indiretta}: l'autenticazione non sulla macchina ma su un server + \item \textbf{Indiretta}: l'autenticazione non avviene sulla macchina ma su un server di logging remoto (Windows domain, radius, kerberos, nis). Un esempio è l'autenticazione che facciamo in laboratorio. L'utente richiede al server l'accesso ad una @@ -45,24 +45,24 @@ \section{Tipi di Autenticazione} \subsection{Autenticazione utente-computer} -L’autenticazione tra un computer ed un utente solitamente avviene tramite -l’utilizzo di \textbf{certificati} (come nel caso bancario); quella tra l’utente -ed un computer avviene sulla base di qualcosa che l’utente: +L'autenticazione tra un computer ed un utente solitamente avviene tramite +l'utilizzo di \textbf{certificati} (come nel caso bancario); quella tra l'utente +ed un computer avviene sulla base di qualcosa che l'utente: \begin{itemize} \item \textit{Conosce}: informazioni quali password, PIN, ecc. - \item \textit{Possiede}: cose fisiche o elettroniche che solo l’utente ha, + \item \textit{Possiede}: cose fisiche o elettroniche che solo l'utente ha, come chiavi convenzionali, carte magnetiche o smart, ecc. \item \textit{È}: caratteristiche biometriche quali - impronte digitali, l’iride, tono di voce, ecc + impronte digitali, l'iride, tono di voce, ecc \end{itemize} \subsection{Autenticazione su conoscenza} Questo metodo si basa sulla conoscenza di una coppia di elementi, \textbf{userID} -e \textbf{password}, che forniscono una prova dell’identità. +e \textbf{password}, che forniscono una prova dell'identità. Esiste un database locale dove si ricerca la coppia di informazioni: -se viene trovata una corrispondenza, l’utente viene riconosciuto. +se viene trovata una corrispondenza, l'utente viene riconosciuto. Questo metodo è \textit{antico} ma \textit{estremamente diffuso} per via della sua economicità e \textit{semplicità} di gestione ed implementazione. Risulta però essere debole e poco resistente una volta scoperta una password, @@ -70,8 +70,8 @@ \subsection{Autenticazione su conoscenza} \subsection{Gestione delle password} -L’utente fornisce userID e password; questi vengono ricercati nel database e se -sono presenti è consentito l’accesso. +L'utente fornisce userID e password; questi vengono ricercati nel database e se +sono presenti è consentito l'accesso. Questo sistema però presenta alcune debolezze. In primo luogo, nel database userID e password sono in chiaro: poteva capitare che queste informazioni venissero utilizzate per entrare illecitamente. Poteva anche presentarsi il @@ -90,17 +90,17 @@ \subsection{Gestione delle password} chiaro e non vi era più la necessità di utilizzare il file memorizzato in RAM. Allo stesso tempo però il file degli hash poteva essere aperto in lettura da chiunque e per due password uguali si aveva il medesimo hash. -Il problema delle password uguali viene risolto con l’aggiunta del \textit{sale} +Il problema delle password uguali viene risolto con l'aggiunta del \textit{sale} (\textbf{salt}), ossia una sequenza di bit generata dal sistema. La password, quindi, risulta diversa dalla sua omonima grazie a questa informazione casuale in più. Nel file viene memorizzato non solo la password, ma anche il sale corrispondente. Questo viene posizionato in una directory nascosta (\textbf{shadow}), in nessun modo accessibile da alcun utente ad eccezione di root. -Per quanto riguarda l’autenticazione, l’utente inserisce la password che conosce: -dal file delle password viene preso il sale dalla riga che corrisponde all’userID +Per quanto riguarda l'autenticazione, l'utente inserisce la password che conosce: +dal file delle password viene preso il sale dalla riga che corrisponde all'userID e si codificano le due informazioni, \(salt + password\). Se il risultato è -uguale alla riga memorizzata nel database, allora l’utente può entrare. +uguale alla riga memorizzata nel database, allora l'utente può entrare. Anche questo file viene aperto in lettura da tutti. Tale problema verrà risolto solo nel 1987. @@ -118,7 +118,7 @@ \subsubsection{Vulnerabilità delle password} \item \textbf{Spoofing}\footnote{Ricordarsi che il termine corretto è \textit{Spoofing} e non \textit{Spooping}, qui lo SCAT non è bene accetto \emoji{poop}}: acquisite da terze parti che impersonano - l’interfaccia di login (Trojan login); + l'interfaccia di login (Trojan login); \end{itemize} @@ -152,11 +152,11 @@ \subsection{Autenticazione su possesso} Chi possiede un oggetto come una carta magnetica, una smart card o smart token, è autorizzato a compiere determinate azioni. Tale tipo di autenticazione solitamente non è nominale, ma può essere accompagnata dal riconoscimento -dell’user. Rubando il token, infatti, non si fa altro che impersonare l’utente. +dell'user. Rubando il token, infatti, non si fa altro che impersonare l'utente. Ogni token memorizza una chiave che deve essere inserita per sbloccarlo. Nel caso del bancomat, per esempio, viene richiesto un PIN per utilizzare la carta. Il vantaggio di questo strumento è che è molto complesso estrarre -un’informazione dal token. +un'informazione dal token. \paragraph{Tipi di Token: } @@ -193,7 +193,7 @@ \subsection{Autenticazione su possesso} \section{Autenticazione su caratteristiche} -Il possesso da parte dell’utente di alcune caratteristiche univoche fornisce +Il possesso da parte dell'utente di alcune caratteristiche univoche fornisce prova della sua identità. Le caratteristiche possono essere: @@ -206,23 +206,25 @@ \section{Autenticazione su caratteristiche} velocità nella scrittura, ecc. \end{itemize} -Lo schema di funzionamento di tale tecnica, prevede una fase iniziale di +Lo schema di funzionamento di tale tecnica prevede una fase iniziale di \textbf{campionamento} in cui vengono eseguite più misurazioni sulla -caratteristica d’interesse, in modo da stabilire un margine d’errore e viene +caratteristica d'interesse, in modo da stabilire un margine d'errore e viene definito un modello (\textbf{template}). Durante la fase di \textbf{autenticazione}, viene confrontata la caratteristica -appena misurata rispetto al template: c’è successo se i due valori corrispondono +appena misurata rispetto al template: c'è successo se i due valori corrispondono a meno di una \textit{tolleranza}, che va definita attentamente. Se è troppo alta consento l'accesso ad altri utenti, se è troppo bassa potrei non consentire l'accesso neanche all'utente a cui magari appartiene la -caratteristica misurata. -Ottenere una perfetta uguaglianza è tecnicamente un’operazione impossibile. -Il problema fondamentale di questa tecnica sta nell’identificare il giusto -template da associare all’individuo in analisi. -Va fatto notare che l’autenticazione biometrica è sempre probabilistica, +caratteristica misurata. +La tolleranza va decisa in base al livello di sicurezza che vogliamo adottare e quindi dall'ambiente di utilizzo. Ad +esempio se utilizzo l'impronta digitale per accedere al conto bancario allora il margine di errore dovrà essere minimo, con il rischio di creare dei falsi negativi. Se invece uso l'impronta digitale per fare accedere degli utenti in piscina allora posso permettermi di impostare un margine elevato ed avere a volte dei falsi positivi, così che i clienti non si lamentino. +Ottenere una perfetta uguaglianza è tecnicamente un'operazione impossibile. +Il problema fondamentale di questa tecnica sta nell'identificare il giusto +template da associare all'individuo in analisi. +Va fatto notare che l'autenticazione biometrica è sempre probabilistica, ovvero dipende da come è settato il parametro soglia: se la soglia -è \textbf{molto bassa} risulterà difficile che l’intruso si autentichi al posto -dell’utente, +è \textbf{molto bassa} risulterà difficile che l'intruso si autentichi al posto +dell'utente, ma il numero di falsi negativi sarà alto; se invece la soglia è \textbf{molto alta}, non avrò mai falsi negativi in quanto l'utente reale verrà sempre autenticato ma potrebbero esserci falsi positivi da parte di un @@ -233,7 +235,7 @@ \section{Autenticazione su caratteristiche} biometrica adatta alla circostanza. Occorre che il sistema non sia troppo invasivo, poiché ciò potrebbe non essere accettato dall'utente. Inoltre, non possono essere utilizzate informazioni che metterebbero a -repentaglio la sua privacy. Per esempio, l’autenticazione tramite retina non +repentaglio la sua privacy. Per esempio, l'autenticazione tramite retina non viene quasi mai impiegata in quanto da essa si potrebbe rinvenire alla presenza di alcune malattie. L'impronta digitale rimane il meccanismo più usato, anche se è il meno pratico ed efficace. diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/bitcoin/imgs/bit33.png b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/bitcoin/imgs/bit33.png index 8e657faf8..04afaaec3 100644 Binary files a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/bitcoin/imgs/bit33.png and b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/bitcoin/imgs/bit33.png differ diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/bitcoin/introduzione.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/bitcoin/introduzione.tex index faca890e9..a5c4c011d 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/bitcoin/introduzione.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/bitcoin/introduzione.tex @@ -2,15 +2,15 @@ \section{Introduzione} \subsection{Blockchain} -La \textit{blockchain} (letteralmente "catena di blocchi") è una struttura dati -\textbf{condivisa} e "\textbf{immutabile}". È definita come un \textit{registro - digitale} le cui voci sono raggruppate in "\textbf{blocchi}", concatenati in +La \textit{blockchain} (letteralmente ``catena di blocchi'') è una struttura dati +\textbf{condivisa} e ``\textbf{immutabile}''. È definita come un \textit{registro + digitale} le cui voci sono raggruppate in ``\textbf{blocchi}'', concatenati in ordine cronologico, e la cui integrità è garantita dall'uso della \textbf{crittografia}. Sebbene la sua dimensione sia destinata a crescere nel tempo, è immutabile in quanto, di norma, il suo contenuto una volta scritto non è più né modificabile né eliminabile, a meno di non invalidare l'intera struttura. Tali tecnologie sono incluse nella più ampia famiglia delle -“\textit{Distributed Ledger}”, ossia sistemi che si basano su un registro +``\textit{Distributed Ledger}'', ossia sistemi che si basano su un registro distribuito, che può essere letto e modificato da più nodi di una rete. Non è richiesto che i nodi coinvolti conoscano l'identità reciproca o si fidino l'uno dell'altro. Difatti, per garantire la coerenza tra le varie copie, l'aggiunta di @@ -29,12 +29,12 @@ \subsection{Blockchain} L'utilizzo di questa tecnologia consente anche di superare il problema dell'infinita riproducibilità di un bene digitale e della doppia spesa, senza l'utilizzo di un server centrale o di un'autorità. Talvolta risulta possibile -che alcuni nodi della rete producano simultaneamente più blocchi "concorrenti" +che alcuni nodi della rete producano simultaneamente più blocchi ``concorrenti'' (ossia collegati a uno stesso blocco già esistente, ma diversi tra loro nel contenuto): ciò dà origine a una biforcazione (fork) nella catena. Il protocollo di aggiornamento specifica quale regola i nodi debbano adottare per selezionare il blocco da accettare, tra quelli concorrenti. I blocchi non selezionati per -l'inclusione nella catena sono chiamati "\textit{blocchi orfani}". +l'inclusione nella catena sono chiamati ``\textit{blocchi orfani}''. \begin{figure}[H] \centering @@ -44,7 +44,7 @@ \subsection{Blockchain} \subsection{Bitcoin} -Il bitcoin si comporta più come “\textit{oro}” che come “moneta” perché il +Il bitcoin si comporta più come ``\textit{oro}'' che come ``moneta'' perché il valore cambia nel tempo. Più che proprietà o possesso di bitcoin/monete si parla di \textit{diritto di spesa}, che si ottiene conoscendo una determinata chiave di cifratura. Si possono inviare e ricevere bitcoin sfruttando una exchange @@ -69,12 +69,14 @@ \subsection{Bitcoin} \item Gli \textbf{utenti} che voglio partecipare all'ecosistema devo essere dotati di un Wallet, \item Un \textbf{wallet} è un software che permette - di gestire in maniera facile le copie di chiavi private-pubbliche, che + di gestire in maniera facile le coppie di chiavi private-pubbliche, che servono per ricevere o dare diritti di spesa/transazioni, \item Le \textbf{transazioni} vengono salvate sui database distribuiti e vengono replicate su tutti i nodi della rete. \end{itemize} +\newpage + \subsubsection{Bitcoin Core} Il software Bitcoin Core\footnote{In inglese Bitcoin Core @@ -93,7 +95,7 @@ \subsubsection{Bitcoin Actors} \begin{figure}[H] \centering - \includegraphics[width=15cm, keepaspectratio]{capitoli/bitcoin/imgs/bit33.png} + \includegraphics[width=14cm, keepaspectratio]{capitoli/bitcoin/imgs/bit33.png} \end{figure} \begin{itemize} @@ -105,7 +107,7 @@ \subsubsection{Bitcoin Actors} \item \textit{Miner} (\emoji{black-circle}): in genere le transazioni da inserire su un blocco sono tantissime, il miner ha il compito di selezionarle e metterle in un blocco (nelle blockchain si può inserire solo un blocco di transazioni - per volta, e non una transazione alla volta ), per poi comunicare le + per volta, e non una transazione alla volta), per poi comunicare le operazioni portate a termine agli altri nodi in modo che tutti aggiornino le informazioni. \end{itemize} @@ -131,20 +133,9 @@ \subsubsection{Miner} Work} e il \textbf{Proof of Stake}. \paragraph{PoW:} -nel proof of work la ricompensa non viene data a tutti i nodi ma al primo che -riesce a risolvere un problema crittografico, questo si aggiudicherà il diritto -di scegliere quale transazione inserire nel blocco. Per risolvere il problema il -miner dovrà trovare una stringa che aggiunta alle transazioni del blocco dia -come risultato \verb|00000xxxxxxxxxxx| una volta hashata. L'unico modo per -ottenere la stringa è facendo dei tentativi per indovinarla. Una volta -verificata la correttezza della stringa dagli altri nodi l'operazione sarà -approvata. La difficoltà per i miner varia in base al numero di \verb|0| -iniziali contenuti nella stringa finale, questi \verb|0| possono essere -aumentati o diminuiti in base al tempo di risoluzione medio impiegato dai miner -(che dovrebbe sempre aggirarsi intorno ai 10 minuti). Infine, prima di -aggiungere definitivamente il blocco, viene inserita una transazione fittizia in -più, chiamata \textbf{Coinbase}, dove viene registrato il fatto che il miner riceve -il suo compenso di nuovi bitcoin. +nel proof of work la ricompensa non viene data a tutti i nodi ma al primo che riesce a minare un blocco (risolvendo un problema crittografico) e ad aggiungerlo alla blockchain. Per risolvere il problema il +miner dovrà prendere un insieme di transazioni non verificate, mettere prima di queste l'hash dell'ultimo blocco presente nella blockchain e inserire in fondo un \emph{nonce}, ovvero un numero randomico. Dovrà poi calcolare l'hash dell'intero blocco, cambiando di volta in volta il nonce, finchè non otterrà un hash che inizi con tanti \verb|0| quanti sono quelli richiesti dal sistema della blockchain in quel momento, \verb|00000xxxxxxxxxxx|. Tale quantità di \verb|0| viene infatti incrementata e decrementata dal sistema affinchè il tempo medio di mining di un blocco rimanga intorno ai 10 minuti. Una volta +verificata la correttezza dell'hash dagli altri nodi l'operazione sarà approvata. Infine, prima di aggiungere definitivamente il blocco, viene inserita una transazione fittizia in più, chiamata \textbf{Coinbase}, dove viene registrato il fatto che il miner riceve il suo compenso di nuovi bitcoin. \subsubsection{Escrow Contracts} diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/bitcoin/sicurezza_blockchain.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/bitcoin/sicurezza_blockchain.tex index eaef83d87..c69905b57 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/bitcoin/sicurezza_blockchain.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/bitcoin/sicurezza_blockchain.tex @@ -5,14 +5,9 @@ \subsection{Double Spending} È un potenziale attacco in cui un bitcoin viene inviato a 2 persone contemporaneamente, benché non sia realizzabile nella blockchain di bitcoin poiché è intrinsecamente resistente fa da base per molti altri attacchi e dunque -spiegheremmo brevemente come funziona. Un miner A invia denaro a due utenti B e -C contemporaneamente, di norma in bitcoin viene approvata la prima transazione -(dato che ci si basa sull'hash e sul timestamp) ma supponiamo che entrambe -vengano approvate in contemporanea su due blocchi diversi, allora entrambe -verranno viste come transazioni valide e ci sarà una possibile fork della -blockchain. In bitcoin però prima o poi una delle due blockchain -risulterà essere più lunga dell'altra e verrà presa quella come blockchain -valida e perciò una delle due transazioni verrà rifiutata. +spiegheremmo brevemente come funziona. Un miner A invia denaro a due utenti (negozi) B e C contemporaneamente, di norma in bitcoin viene approvata la prima transazione +(dato che ci si basa sull'hash e sul timestamp) ma supponiamo che entrambe vengano approvate in contemporanea su due blocchi diversi, allora entrambe verranno viste come transazioni valide e ci sarà una possibile fork della +blockchain. In bitcoin però prima o poi una delle due blockchain risulterà essere più lunga dell'altra e verrà presa quella come blockchain valida e perciò una delle due transazioni verrà rifiutata ma nel mentre il miner ha già ricevuto gli oggetti comprati sui negozi B e C. La soluzione a tale problema è che i negozianti, prima di inviare le proprie merci, devono aspettare che la propria transazione risulti assere aggiunta in maniera definitiva alla blockchain e ciò avviene dopo il mining di altri 6 blocchi rispetto a quello dove è tale transazione (circa 1 ora di attesa). \subsubsection{51\% Attack} @@ -26,8 +21,7 @@ \subsubsection{51\% Attack} Per imporre i suoi blocchi, un'organizzazione dovrebbe controllare il 51\% dei nodi (è detto 51\% attack), per avere potenza di calcolo sufficiente a produrre (con buona probabilità) catene di blocchi lunghe prima di tutti gli altri nodi, -ciò è altamente improbabile. Non è possibile che questo attacco abbia successo -perché nessuno dispone di una potenza di calcolo così elevata. +ciò è altamente improbabile. Attualmente non è possibile che questo attacco abbia successo perché nessuno dispone di una potenza di calcolo così elevata ma ci sono comunque delle \emph{mining pool} che accrescono quotidianamente la propria hash power (la più grande ha circa il 30\%). \subsection{Wallet attack} diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/cap_1/cia.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/cap_1/cia.tex index 7a4f078a2..5cd0408c1 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/cap_1/cia.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/cap_1/cia.tex @@ -6,10 +6,10 @@ \section{C.I.A.} dire \textbf{Confidentiality} (\textit{Riservatezza}), \textbf{Integrity} (\textit{Integrità}) e \textbf{Availability} (\textit{Disponibilità}) -(detta anche “\textit{Triade C.I.A.}"). +(detta anche ``\textit{Triade C.I.A.}''). Tali principi devono essere ricercati in ogni soluzione di sicurezza, tenendo conto anche delle implicazioni introdotte dalle vulnerabilità e dai rischi. -Per questo motivo vengono detti “componenti base”: +Per questo motivo vengono detti ``componenti base'': \paragraph{Riservatezza dei Dati:} @@ -34,7 +34,7 @@ \section{C.I.A.} non solo la necessità di voler nascondere il contenuto di un documento da occhi indesiderati, ma anche la sua esistenza. Se consideriamo, ad esempio, l’analisi di un sistema di comunicazione, potremmo certamente non essere in grado di leggere -i messaggi da due utenti, ma allo stesso tempo potremmo derivare informazioni +i messaggi tra due utenti, ma allo stesso tempo potremmo derivare informazioni importanti in base alla frequenza di scambio di messaggi. Pensiamo, ad esempio, alla frequenza di messaggi scambiati da un Server bancario rispetto a quella di un semplice utente. diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/cap_1/concetti_correlati.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/cap_1/concetti_correlati.tex index 823352e47..9875e59a8 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/cap_1/concetti_correlati.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/cap_1/concetti_correlati.tex @@ -2,8 +2,8 @@ \section{Concetti Correlati} \subsection{Assurance} -Il concetto di “\textit{Garanzia}” non è formalmente legato al sistema su cui si -effettua un’analisi di sicurezza informatica. Spesso, infatti, una minaccia +Il concetto di ``\textit{Garanzia}'' non è formalmente legato al sistema su cui si +effettua un'analisi di sicurezza informatica. Spesso, infatti, una minaccia alla sicurezza è dovuta dall'utenza stessa del sistema considerato. Pensiamo per esempio ad un impiegato negligente che involontariamente permette ad un virus di infettare il proprio computer, dopo aver inserito una USB. @@ -11,7 +11,7 @@ \subsection{Assurance} potrebbero di fatto rendere inutili gli sforzi effettuati dall'organizzazione per evitare che minacce esterne compromettano il proprio sistema informatico. Un comportamento sbagliato da parte del personale infatti è spesso più rischioso -rispetto ai tentativi di intrusione da parte di attaccanti esterni all’organizzazione. +rispetto ai tentativi di intrusione da parte di attaccanti esterni all'organizzazione. La natura umana non permette di creare dei protocolli di sicurezza in grado di difendere i propri sistemi da cattive abitudini o da un atteggiamento noncurante degli operatori. Solitamente ogni organizzazione utilizza delle policy aziendali @@ -22,10 +22,10 @@ \subsection{Assurance} \subsection{Minacce} Una minaccia (\textbf{threat}) è una potenziale violazione della sicurezza. -In realtà non è necessario che avvenga concretamente una violazione per essere +In realtà non è necessario che avvenga concretamente una violazione; per essere considerata una minaccia basta il solo fatto che ci sia la possibilità che il sistema debba essere protetto. -Le azioni che causano una minaccia sono chiamati \textbf{attacchi}. Coloro che +Le azioni che causano una minaccia sono chiamate \textbf{attacchi}. Coloro che mettono in pratica queste azioni, o permettono che esse siano eseguite, sono invece chiamati \textbf{attaccanti}. Le \textit{minacce} possono essere classificate in: @@ -34,7 +34,7 @@ \subsection{Minacce} \item \textit{Disclosure}: accesso non autorizzato alle informazioni (violazione della riservatezza); \item \textit{Deception}: accettazione di dati falsi - (violazione dell’integrità e dell’autenticazione); + (violazione dell'integrità e dell'autenticazione); \item \textit{Disruption}: corrisponde al DoS (violazione della disponibilità); \item \textit{Usurpation}: controllo non autorizzato di un sistema o parte @@ -45,36 +45,35 @@ \subsection{Minacce} \begin{itemize} \item \textbf{Snooping}: È una minaccia di tipo \textit{Disclosure}. - Consiste nell’ascolto o nella lettura passiva (intercettazione) di - informazioni. Si parla di \textit{Wiretapping} passivo se l’oggetto + Consiste nell'ascolto o nella lettura passiva (intercettazione) di + informazioni. Si parla di \textit{Wiretapping} passivo se l'oggetto di ascolto è la rete stessa. La riservatezza si occupa di evitare che questa minaccia possa essere applicata; \item \textbf{Modification}: Consiste nella modifica non autorizzata delle - informazioni. Copre tre classi di minacce. L’obiettivo potrebbe essere - una \textit{Deception} se l’intenzione è fare in modo che i dati siano + informazioni. Copre tre classi di minacce. L'obiettivo potrebbe essere + una \textit{Deception} se l'intenzione è fare in modo che i dati siano accettati in modo alterato. Potrebbe essere una \textit{Disruption} - ed una \textit{Usurpation} se la modifica dei dati consente l’esecuzione + ed una \textit{Usurpation} se la modifica dei dati consente l'esecuzione di azioni non legittime. Il \textit{Wiretapping} attivo se i dati che transitano nella rete sono soggetti ad una modifica non autorizzata. - Un esempio di attacco è il “\textbf{man-in-the-middle}”, nel quale un + Un esempio di attacco è il ``\textbf{man-in-the-middle}'', nel quale un intruso legge i messaggi dal mittente e li invia modificati al - destinatario senza farsi notare. L’integrità si occupa di evitare che + destinatario senza farsi notare. L'integrità si occupa di evitare che questa minaccia possa essere applicata; \item \textbf{Masquerading o Spoofing}: Si tratta di un furto di identità. È un attacco di tipo \textit{Deception} e \textit{Usurpation}. - Si basa sul far credere ad una vittima che l’entità con cui sta - comunicando è un’altra. L’integrità si occupa di evitare che questa + Si basa sul far credere ad una vittima che l'entità con cui sta + comunicando è un'altra. L'integrità si occupa di evitare che questa minaccia possa essere applicata; - \item \textbf{Ripudio dell’origine}: Si tratta di una forma di \textit{Deception} - che consiste nel negare l’origine (invio o creazione) di un determinato - elemento (ad esempio di un messaggio). L’integrità si occupa di questo + \item \textbf{Ripudio dell'origine}: Si tratta di una forma di \textit{Deception} + che consiste nel negare l'origine (invio o creazione) di un determinato + elemento (ad esempio di un messaggio). L'integrità si occupa di questo attacco; \item \textbf{Ripudio della ricezione}: Si tratta di una forma di \textit{Deception} che consiste nel negare di aver ricevuto un determinato elemento. - L’integrità si occupa di questo attacco; + L'integrità si occupa di questo attacco; \item \textbf{Denial of Service}: Consiste in una negazione a lungo termine - di un servizio. È una forma di \textit{Usurpation}, sebbene possa - rientrare anche nella \textit{Disruption}. L’attaccante non permette + di un servizio. È una forma di \textit{Disruption}. L'attaccante non permette ad un server di fornire un servizio. \end{itemize} @@ -88,18 +87,18 @@ \subsection{Policy e Meccanismi} I \textbf{Meccanismi} sono i metodi che ci consentono di individuare, prevenire e ripristinare le minacce. Una volta individuati i rischi in termini di sicurezza ed i loro effetti, si stabiliscono quali contromisure adottare. -L’affidabilità di un meccanismo di sicurezza richiede diverse assunzioni: +L'affidabilità di un meccanismo di sicurezza richiede diverse assunzioni: \begin{enumerate} \item Ogni meccanismo è stato ideato per implementare una o più richieste di una politica di sicurezza; - \item L’unione di tutti i meccanismi copre tutti gli aspetti della policy + \item L'unione di tutti i meccanismi copre tutti gli aspetti della policy di sicurezza; \item Il meccanismo è stato implementato correttamente; \item Il meccanismo è installato e amministrato correttamente. \end{enumerate} -Un meccanismo di sicurezza tipico è dato dalla verifica dell’identità prima di +Un meccanismo di sicurezza tipico è dato dalla verifica dell'identità prima di cambiare una password. Esistono meccanismi di: @@ -112,10 +111,10 @@ \subsection{Policy e Meccanismi} un attacco. Le possibili alternative sono: \begin{itemize} - \item il blocco dell’attacco e la riparazione dei danni causati. + \item il blocco dell'attacco e la riparazione dei danni causati. \item non si agisce sull'attacco ma si immagazzinano informazioni sull'attaccante; \item ritorsione (retaliation) eseguendo un attacco verso - l’attaccante. + l'attaccante. \end{itemize} \end{itemize} \ No newline at end of file diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/cap_1/introduzione.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/cap_1/introduzione.tex index 5d38e71ed..00c71278b 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/cap_1/introduzione.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/cap_1/introduzione.tex @@ -10,9 +10,10 @@ \section{La Sicurezza Informatica} Crittografia, firewall, antivirus, utilizzo di password e smart card sono solo dei meccanismi, degli strumenti e delle tecniche usati per ottenere una maggiore sicurezza. Il loro utilizzo deve essere ponderato in relazione al loro costo: -bisogna sempre chiedersi “\textit{conviene fare l'investimento per acquistare un firewall, - ecc... o conviene risparmiare nell'ambito della sicurezza?}”. In sostanza, va +bisogna sempre chiedersi ``\textit{conviene fare l'investimento per acquistare un firewall, + ecc... o conviene risparmiare nell'ambito della sicurezza?}''. In sostanza, va sempre valutato il rapporto costo/benefici.\\ + Un \textbf{piano di sicurezza} è composto da diverse fasi: \begin{itemize} @@ -51,7 +52,7 @@ \section{La Sicurezza Informatica} \item non deve essere sicura solo la rete o solo il sistema operativo, ma tutto nel complesso; \item non è un semplice predicato booleano, infatti al quesito - “il sistema è sicuro?” non si può + ``il sistema è sicuro?'' non si può rispondere semplicemente sì o no; \item è costosa nel senso di risorse computazionali, gestione, mentalità, utilizzo; \item rimane un campo aperto anche per i colossi dell'Informatica. diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/certificato_digitale.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/certificato_digitale.tex index 321b0e926..d5ff582c9 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/certificato_digitale.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/certificato_digitale.tex @@ -35,17 +35,17 @@ \subsection{Formato x.509} Il formato più comune per i certificati di chiave pubblica è definito da X.509, raccomandato dalla ITU (International Telecommunication Union). -Il certificato viene firmato da chi lo emette. “Codice identificativo -dell'emittente” è univoco per ogni +Il certificato viene firmato da chi lo emette. ``Codice identificativo +dell'emittente'' è univoco per ogni CA esistente. La firma garantisce il fatto che il documento è autentico, cioè che è stato scritto dal -“nome soggetto” e che è stato verificato da “ente emettitore”. -E' importante specificare il “periodo di validità” poiché la stessa firma +``nome soggetto'' e che è stato verificato da ``ente emettitore''. +E' importante specificare il ``periodo di validità'' poiché la stessa firma (e la coppia chiave pubblica-privata) ha una validità temporale. Se questa dovesse scadere, il certificato va riemesso. Ciò viene fatto anche nel momento in cui i ruoli (specificati nel campo -“estensioni”) di chi partecipa +``estensioni'') di chi partecipa alla sottoscrizione cambiano. Viene anche specificato l'elenco degli algoritmi utilizzati per l'apposizione della firma con i relativi @@ -79,7 +79,7 @@ \subsection{Ottenere un certificato Digitale} sono ammessi più LVP. Una PKI può avere una struttura gerarchica in cui alcune CA certificano altre CA, ottenendo una -“catena di fiducia”. Secondo tale struttura: la “Root CA” certifica le +``catena di fiducia''. Secondo tale struttura: la ``Root CA'' certifica le CA di primo livello; le CA di primo livello certificano le CA di secondo livello; le CA di ultimo livello certificano il singolo utente. diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/chiave_privata.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/chiave_privata.tex index d27f6bb0f..15193f991 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/chiave_privata.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/chiave_privata.tex @@ -1,4 +1,4 @@ -\section{Crittografia a chiave Privata (simmetrica)} +\section[Crittografia a chiave Privata (simmetrica)]{Crittografia a chiave Privata \\(simmetrica)} \begin{figure}[H] \centering diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/chiave_pubblica.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/chiave_pubblica.tex index d86a69da0..df7d60fb8 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/chiave_pubblica.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/chiave_pubblica.tex @@ -1,4 +1,4 @@ -\section{Crittografia a chiave Pubblica (asimmetrica)} +\section[Crittografia a chiave Pubblica (asimmetrica)]{Crittografia a chiave Pubblica \\(asimmetrica)} La crittografia asimmetrica, conosciuta anche come crittografia a coppia di chiavi, crittografia a @@ -20,8 +20,17 @@ \section{Crittografia a chiave Pubblica (asimmetrica)} \centering \includegraphics[width=\textwidth, keepaspectratio]{capitoli/crittografia/imgs/pubblica.png} \caption{Esempio del funzionamento della Crittografia Asimmetrica.} + \label{fig:crittografia_asimmetrica} \end{figure} +\newpage + +In Figura~\ref{fig:crittografia_asimmetrica} va fatto notare come: +\begin{itemize} + \item il mittente cifra il messaggio con la sua chiave privata così che tutti possano decifrarlo con la sua chiave pubblica. La cifratura in questo caso ha il solo scopo di garantire l'\textbf{integrità} del messaggio. + \item il mittente cifra il messaggio con la chiave pubblica del destinatario così che solo il destinatario, con la propria chiave privata, potrà decifrarlo, garantendo la \textbf{confidenzialità} del messaggio. +\end{itemize} + Gli attacchi a sistemi di crittografici sono detti attacchi di \textbf{Crittoanalisi} e come obbiettivo hanno quello di provare a dedurre la chiave che gli @@ -31,11 +40,11 @@ \section{Crittografia a chiave Pubblica (asimmetrica)} \begin{itemize} \item \textbf{CypherText only}: è noto solo il testo codificato; \item \textbf{Known plaintext}: il messaggio è cifrato ma il testo in chiaro è noto; - \item \textbf{Chosen plaintext}: il testo in chiaro viene scelto in quale modo (per es. tutti 0, tutti 1, ecc); + \item \textbf{Chosen plaintext}: l'attaccante può cifrare messaggi in chiaro da lui scelti per ottenere il ciphertext ed eseguirne l'analisi; \item \textbf{Brute-force}: forza bruta, tentativi di attacco alla chiave finché non si trova quella giusta; \end{itemize} -\paragraph{Crittografia Perfetta: } la crittografai si di dice Perfetta quando +\paragraph{Crittografia Perfetta: } la crittografia si di dice ``Perfetta'' quando nessun testo codificato rilascia informazione alcuna né sulla chiave usata per la codifica, né sul testo in chiaro, diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/firma_digitale.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/firma_digitale.tex index d04310f73..f766be0f0 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/firma_digitale.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/firma_digitale.tex @@ -34,7 +34,7 @@ \subsection{Creazione della Firma} chiaro una funzione di hash appositamente studiata che produce una stringa binaria di lunghezza costante e piccola, normalmente 128 o 160 -bit, chiamata “digest message”, ossia impronta +bit, chiamata ``digest message'', ossia impronta digitale. Poiché la dimensione del digest message è fissa, e molto più piccola di quella del messaggio diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/hash.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/hash.tex index 52f9558c5..edc2d4498 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/hash.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/hash.tex @@ -1,12 +1,12 @@ \section{Funzioni Hash} -Una funzione di hash è una funzione matematica che permette di ridurre una +Una funzione hash è una funzione matematica che permette di ridurre una qualunque stringa di testo (indipendentemente dalla sua lunghezza) in una nuova stringa avente precise caratteristiche tra cui un numero di caratteri predefinito. A partire da un input X, in altre parole, sarà possibile -generare un input Y che avrà delle caratteristiche ben definite. +generare un output Y che avrà delle caratteristiche ben definite. A prescindere dal tipo di funzione di hashing tutte hanno dei punti in comune: \begin{itemize} @@ -17,9 +17,9 @@ \section{Funzioni Hash} output; \item \textbf{Irreversibilità}: mentre è sempre possibile riprodurre l'output conoscendo l'input originario - col quale l'output è stato generato non è però possibile fare - il percorso inverso, non si può - quindi a partire da una stringa alfanumerica risalire al contenuto + col quale l'output è stato generato, non è però possibile fare + il percorso inverso. Non si può + quindi, a partire da una stringa alfanumerica (output), risalire al contenuto iniziale dell'input; \item \textbf{Determinismo}: indipendentemente da quanto sia lungo l'input, la funzione di hash restituirà @@ -28,4 +28,6 @@ \section{Funzioni Hash} complesso, è sufficiente una variazione infinitesimale dell'input per generare un output completamente differente; -\end{itemize} \ No newline at end of file +\end{itemize} + +Alcune funzioni hash (come MD5 e SHA1) sono notoriamente conosciute a causa della loro vulnerabilità ai ``Rainbow Table Attack'' \emoji{rainbow}, ovvero attacchi in cui sono stati creati dizionari che riportano la corrispondenza tra una parola e relativo hash. Così facendo un attaccante può comodamente usare uno dei molteplici siti web\footnote{Uno dei più famosi è sicuramente \href{https://crackstation.net/}{CrackStation}.} o scaricare direttamente un dizionario\footnote{Esistono rainbow table da svariati Tb scaricabili gratuitamente su \href{https://freerainbowtables.com/}{Free Rainbow Tables}.} per verificare se l'hash di una password che ha trovato è stato già craccato, senza doversi preoccupare di dover effettuare un \emph{bruteforce} sull'hash. \ No newline at end of file diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/imgs/Mulan.png b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/imgs/Mulan.png index 9e2e8fe0c..1ad66e787 100644 Binary files a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/imgs/Mulan.png and b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/imgs/Mulan.png differ diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/imgs/alienospinning.png b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/imgs/alienospinning.png index 755a2c27b..b74c5c51a 100644 Binary files a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/imgs/alienospinning.png and b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/imgs/alienospinning.png differ diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/introduzione.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/introduzione.tex index 149a81eac..19095729c 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/introduzione.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/introduzione.tex @@ -3,7 +3,7 @@ \section{Introduzione} La crittografia è una scienza antichissima che consiste nel codificare e decodificare l'informazione. L'operazione di codifica permette di ottenere un testo codificato a partire da -un “testo in chiaro” che +un ``testo in chiaro'' che può essere letto da tutti. L'operazione di decodifica invece, consiste nel ricavare un testo in chiaro partendo da un diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/protocolli_sicurezza.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/protocolli_sicurezza.tex index bee747ca5..e754c6110 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/protocolli_sicurezza.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/crittografia/protocolli_sicurezza.tex @@ -12,15 +12,15 @@ \section{Protocolli di Sicurezza} In crittografia il termine nonce indica un numero, generalmente casuale o pseudo-casuale, che ha un utilizzo unico. Nonce deriva infatti dall'espressione inglese -“for the nonce”, che significa -appunto "per l'occasione". Un nonce viene utilizzato spesso nei protocolli +``for the nonce'', che significa +appunto ``per l'occasione''. Un nonce viene utilizzato spesso nei protocolli di autenticazione per assicurare che i dati scambiati nelle vecchie comunicazioni non possano essere utilizzati in attacchi di tipo replay attack.\\ -In ogni protocollo viene utilizzata una \textbf{spia DY}, la quale possiede una serie di capacità che le -permettono di individuare l'intruder: +\paragraph{La spia DY:} +In tutti i protocolli di autenticazione che analizzeremo di seguito, viene identificata la possibilità che vi sia una ``spia'' (intruder) all'interno del sistema che può effettuare una serie di operazioni, quali: \begin{itemize} \item Intercettare messaggi e prevenirne il recapito; \item Far rimbalzare a piacere i messaggi intercettati; @@ -53,7 +53,7 @@ \section{Protocolli di Sicurezza} \item Nonce: \(N_a\), \(N_b\), \(\ldots \) \item Timestamp: \(T_a\), \(T_b\), \(\ldots \) \item Digest - \item Label: “trasferisci denaro”, “collegati alla porta xy”, \(\ldots \) + \item Label: ``trasferisci denaro'', ``collegati alla porta xy'', \(\ldots \) \end{itemize} I messaggi base possono essere a loro volta composti: @@ -67,25 +67,17 @@ \section{Protocolli di Sicurezza} \begin{figure}[H] \centering - \includegraphics[width=\textwidth, keepaspectratio]{capitoli/crittografia/imgs/alieno.png} + \includegraphics[width=10cm, keepaspectratio]{capitoli/crittografia/imgs/alieno.png} \end{figure} Alice vuole identificarsi con Bob, quindi Bob alla fine dell'applicazione del protocollo dovrà essere sicuro di aver comunicato con Alice. \begin{enumerate} - \item Alice invia un messaggio criptato con la - chiave pubblica di Bob, che quindi solo lui potrà - aprire. Il nonce \(N_a\) permette di capire se il - messaggio che è stato inviato è nuovo. Si - analizzano tutte i nonce già utilizzate per - verificare che essa sia appunto un valore mai - visto; + \item Alice invia un messaggio a Bob, criptato con la + chiave pubblica di quest'ultimo e che quindi solo lui potrà aprire, in cui inserisce chi lo sta contattando ed un nonce. Il nonce \(N_a\) permette di capire se il messaggio che è stato inviato è nuovo. Si analizzano tutti i nonce già utilizzati per verificare che esso sia appunto un valore mai visto; \item Bob riceve il messaggio e lo apre. Una volta letto, risponde ad Alice: invia indietro il nonce - \(N_a\) ricevuta più uno nuovo, \(N_b\), questa volta - per fare in modo che sia lui ad autenticarsi con - Alice. Il messaggio è codificato con la - chiave pubblica \(K\) di Alice; + \(N_a\) ricevuto, più ne aggiunge uno nuovo, \(N_b\), questa volta per fare in modo che sia lui ad autenticarsi con Alice. Il messaggio è codificato con la chiave pubblica di Alice, \(K_{alice}\); \item Alice riceve la risposta e invia a sua volta \(N_b\) a Bob. A questo punto Bob è sicuro di poter parlare con Alice. @@ -136,7 +128,7 @@ \subsection{Attacco di Lowe (1995)} elemento \(N_a\) (il nonce di Alice), e come secondo elemento \(N_b\) (il nonce di Bob) che Alice crede sia stato generato da Ive; - \item[3.] Alice inoltra \(N_b\) ad Ive criptando con la \(K\) di Ive; + \item[3.] Alice inoltra \(N_b\) ad Ive criptando con la chiave di Ive, \(K_{ive}\); \item[3'.] Ive apre il messaggio e lo invia a Bob, criptato con \(K_{bob}\) \end{enumerate} @@ -156,10 +148,10 @@ \subsection{Attacco di Lowe (1995)} Lo stesso tipo di attacco può essere studiato nella tassonomia BUG. Tale soluzione è deprecata ma continua ad essere utilizzata. -Sappiamo che Alice ha condiviso con Ive il nonce \(N_a\) da lei generata, ma -questa in realtà è stata -inoltrata anche a Bob. Bob, nel caso in cui avesse delle intenzioni -malevole, potrebbe utilizzare \(Na\) +Sappiamo che Alice ha condiviso con Ive il nonce \(N_a\) da lei generato, ma +questo in realtà è stato +inoltrato anche a Bob. Bob, nel caso in cui avesse delle intenzioni +malevole, potrebbe utilizzare \(N_a\) ai danni di Alice: se Alice vedesse arrivare un messaggio contenente \(N_a\) e \(N_b\), infatti, penserebbe che questo sia stato inviato da Ive. Bob però, conoscendo l'importanza di @@ -179,21 +171,21 @@ \section{Protocollo di sicurezza di Woo-Lam (anni 80)} possiede un database di tutte le chiavi. Un TTP è un'entità che facilita le interazioni tra due parti che si fidano entrambe -della “terza parte”. +della ``terza parte''. L'obiettivo del protocollo è che Alice (\(A\)) riesca ad autenticarsi con Bob (\(B\)). \begin{figure}[H] \centering - \includegraphics[width=8cm, keepaspectratio]{capitoli/crittografia/imgs/Mulan.png} + \includegraphics[width=7cm, keepaspectratio]{capitoli/crittografia/imgs/Mulan.png} \end{figure} \begin{enumerate} \item A invia un messaggio pubblico a B; - \item B invia ad A una nonce \(N_b\) per verificare che stia + \item B invia ad A un nonce \(N_b\) per verificare che stia effettivamente comunicando con lei. Anche questo messaggio è pubblico; - \item A riceve \(N_b\) e la inoltra di risposta a Bob, ma criptata con + \item A riceve \(N_b\) e lo inoltra di risposta a Bob, ma criptata con \(K_a\). \(K_a\) è una chiave simmetrica che ha in condivisione con il TTP e che B non può aprire. Bob deve verificare che \(K_a\) appartenga davvero ad A; @@ -202,50 +194,45 @@ \section{Protocollo di sicurezza di Woo-Lam (anni 80)} può aprire solo il TTP poiché condivide le chiavi simmetriche con B; \item Il TTP, una volta decifrato il messaggio e ottenuto \(N_b\), lo inoltra a B. B apre il messaggio finale perché possiede \(K_b\) e - verifica che \(N_b\) sia la nonce che ha inviato ad A. Se è così, + verifica che \(N_b\) sia il nonce che ha inviato ad A. Se è così, significa che B ha effettivamente comunicato con A. La decodifica di \(\{N_b\}_{K_a}\) funziona solo se \(K_a\) appartiene ad A. \end{enumerate} \subsection{Attacco su Woo-Lam} -Anche detto “interlacciamento di sessioni”. +Anche detto ``interlacciamento di sessioni''. \begin{figure}[H] \centering \includegraphics[width=8cm, keepaspectratio]{capitoli/crittografia/imgs/mulan2.png} \end{figure} \begin{enumerate} - \item[1.] C è l'attaccante che si vuole spacciare per A con + \item[1.] C'è l'attaccante C che si vuole spacciare per A con B e invia un messaggio a B confermando ciò; \item[1'.] C invia anche un altro messaggio a B dove afferma invece di essere C; Alla ricezione dei due messaggi, B segue il protocollo e genera due nonce; \item[2.] In risposta ad A genera \(N_b\); \item[2'.] In risposta a C genera \(N_b'\); - C intercetta i messaggi e quindi anche le due nonce. - \item[3/3'.] C invia \(N_b\) criptata con \(K_c\) a B due volte; + C intercetta i messaggi e quindi anche i due nonce. + \item[3/3'.] C invia \(N_b\) criptato con \(K_c\) a B due volte; B quindi riceve lo stesso messaggio due volte. \item[4.] Supponendo che un messaggio sia stato inviato - da A, B invia al TTP la nonce \(N_b\) che ha ricevuto. Il + da A, B invia al TTP il nonce \(N_b\) che ha ricevuto. Il messaggio è poi criptato con \(K_b\); \item[4'.] B invia un altro messaggio al TTP ma questa volta con C all'interno. - \item[5.] TTP invia a B la nonce \(N_b''\) ottenuta a partire dalla + \item[5.] TTP invia a B il nonce \(N_b''\) ottenuto a partire dalla decifratura del messaggio 4 (nonce completamente - sbagliata); - \item[5'.] TTP invia a B la nonce \(N_b'\) ottenuta a partire dalla - decifratura del messaggio 4 + sbagliato); + \item[5'.] TTP invia a B il nonce \(N_b\) ottenuto a partire dalla + decifratura del messaggio 4' \end{enumerate} -B si renderà conto del fatto che \(N_b'\) è stata inviata da A. Quindi B ha -autenticato C al posto di A, -Infatti, il messaggio di autenticazione che avrebbe dovuto prendere in -considerazione era il 4 con -nonce \(N_b''\). -Se B attiva due comunicazioni contemporaneamente, non può sapere in che -ordine arriveranno i -messaggi. -Il protocollo sembrerebbe funzionare ma in realtà non è così. +B aveva associato ad A il nonce \(N_b\) quindi quando gli verrà ritornato penserà che è stato inviato da A. B andrà allora ad autenticare C al posto di A. Inoltre, se B attiva due comunicazioni contemporaneamente non può sapere in che ordine arriveranno i messaggi a causa del funzionamento di HTTP, quindi si potrebbe vedere ricevere prima il nonce ``corretto'' (quello inviato da TTP per C nel messaggio 4') invece che quello ``corrotto'' (inviato da TTP per A nel messaggio 4).\\ + +Il protocollo Woo-Lam è quindi vulnerabile. Per risolvere teoricamente basta che il TTP inserisca nel messaggio di ritorno quello che è l'utente per il quale ha decifrato il nonce.\\ + Si porta all'attenzione dell'egregio lettore che esiste anche la versione simmetrica di Needham-Schröder (questa è un informazione dalla dubbia utilità). \ No newline at end of file diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/confidentiality.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/confidentiality.tex index fbee7f29f..3ca98d867 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/confidentiality.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/confidentiality.tex @@ -1,6 +1,6 @@ \section{Confidentiality Policies} -Una politica di riservatezza, chiamata anche “information flow policy”, +Una politica di riservatezza, chiamata anche ``information flow policy'', impedisce la divulgazione non autorizzata di informazioni. Il suo obiettivo è quello di specificare quali dati devono essere @@ -17,17 +17,14 @@ \section{Confidentiality Policies} gli oggetti (persone o processi). \end{itemize} -Un modello di sicurezza definisce i soggetti, gli oggetti ai quali i soggetti +Un modello di sicurezza definisce i soggetti e gli oggetti ai quali i soggetti hanno accesso ed i diritti di accesso, che non sono altro che le operazioni con le quali è possibile operare. Un soggetto può avere diritti di accesso sia per gli oggetti che per altri soggetti. Esistono due tipi di modelli di sicurezza: \begin{itemize} - \item \textit{Discretionary access control} (\textbf{DAC}): meccanismo - attraverso il quale gli utenti possono - liberamente decidere di garantire o revocare l'accesso a determinati - oggetti. + \item \textit{Discretionary access control} (\textbf{DAC}): meccanismo attraverso il quale i proprietari di un file possono liberamente decidere di garantire o revocare l'accesso ad altri utenti per quel file. In particolare si ha che: \begin{itemize} \item Gli utenti amministrano i dati che possiedono (vengono detti proprietari); @@ -60,20 +57,20 @@ \subsection{Modello Bell-LaPadula} rafforzare i controlli ai possibili accessi alle applicazioni militari (corrisponde, infatti, alle classificazioni -stile-militare). Viene anche chiamato modello “\textit{a multi-livelli}”. +stile-militare). Viene anche chiamato modello ``\textit{a multi-livelli}''. Nelle applicazioni i soggetti e gli oggetti vengono partizionati in differenti livelli di sicurezza. Un soggetto può solo accedere ad oggetti a certi livelli, i quali dipendono strettamente dal loro livello di sicurezza. Per esempio, i seguenti sono due tipici specificazioni di -accessi: “una persona -\verb|UNCLASSIFIED| non può leggere informazioni a livello \verb|CONFIDENTIAL|” e -“informazioni \verb|TOP SECRET| non possono essere scritte in files di livello -\verb|UNCLASSIFIED|”. +accessi: ``una persona +\verb|UNCLASSIFIED| non può leggere informazioni a livello \verb|CONFIDENTIAL|'' e +``informazioni \verb|TOP SECRET| non possono essere scritte in files di livello +\verb|UNCLASSIFIED|''. Gli oggetti sono classificati in 4 diversi livelli di sensibilità, cioè di confidentiality. Ciascun oggetto può essere associato a uno o più livelli, detti compartments. -Ad ogni soggetto, invece, viene associata una “\textit{clearance}” ovvero +Ad ogni soggetto, invece, viene associata una ``\textit{clearance}'' ovvero un'autorizzazione. Una clearance non è altro che una coppia del tipo \verb|| dove \verb|rank| è il massimo livello di sensibilità dell'informazione a cui @@ -82,8 +79,8 @@ \subsection{Modello Bell-LaPadula} A tutte le entità vengono assegnati dei livelli di sicurezza. In particolare: \begin{itemize} - \item Un soggetto S possiede “\textit{security clearance}” \(L(S)=l_s\); - \item Un oggetto O possiede “\textit{security classification}” \(L(O)=l_o\); + \item Un soggetto S possiede ``\textit{security clearance}'' \(L(S)=l_s\); + \item Un oggetto O possiede ``\textit{security classification}'' \(L(O)=l_o\); \end{itemize} Per ogni classificazione di sicurezza \(l_i, \ i=0,...,k-1 \ con \ l_i r \rightarrow r \in authr(S) \ ] -\]\footnote{È inutile ed incomprensibile, ma era carina da vedere.} + (\forall s \in S)[ \ r' \in authr(s) \wedge r' > r \rightarrow r \in authr(S) \ ]\footnote{È inutile ed incomprensibile, ma era carina da vedere.} +\] In tale modello è applicabile il principio di ereditarietà: @@ -303,8 +300,8 @@ \subsubsection{Modello RBAC-NIST} \[ (\forall r_1, r_2 \in R) [ \ r_2 \in meauth(r_1) \rightarrow - [ \ (\forall s \in S) [ \ r_1 \in authr(s) \rightarrow r_2 \notin authr(s) \ ] \ ] \ ] -\] \footnote{Anche questa è inutile ed incomprensibile, ma carina da vedere.} + [ \ (\forall s \in S) [ \ r_1 \in authr(s) \rightarrow r_2 \notin authr(s) \ ] \ ] \ ]\footnote{Anche questa è inutile ed incomprensibile, ma carina da vedere.} +\] In pratica, la \textit{Separation of Duty} stabilisce che se un ruolo \(r_2\) è in conflitto con un ruolo \(r_1\), diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/imgs/clark_wilson.png b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/imgs/clark_wilson.png index ea1c1c3ef..5337563fe 100644 Binary files a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/imgs/clark_wilson.png and b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/imgs/clark_wilson.png differ diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/integrity.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/integrity.tex index 6f60c97e2..9ef0f1b11 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/integrity.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/integrity.tex @@ -9,7 +9,7 @@ \section{Integrity Policies} avere una maggiore integrità rispetto al freeware scaricato da internet. \item \textbf{Il livello di integrità di un oggetto} descrive il grado - di “affidabilità” dell'informazione + di ``affidabilità'' dell'informazione contenuta in quell'oggetto. \end{itemize} @@ -27,7 +27,7 @@ \section{Integrity Policies} \'{E} importante precisare che avere un alto livello di integrità non significa avere un alto livello di confidenzialità e viceversa. -In generale se P è un processo con un grado X di “affidabilità” +In generale se P è un processo con un grado X di ``affidabilità'' (\textbf{trustworthiness}) non può modificare dati ad un livello più alto di lui perché è certificato solo fino a quel punto; quindi può @@ -71,16 +71,16 @@ \subsection{Modello BIBA} rispecchino il mondo reale). \end{itemize} +\newpage + Implementa le protezioni definendo una serie ordinata di livelli di integrità per i soggetti e gli oggetti, rispettando le regole: \begin{itemize} - \item \textbf{Read Up:} Questo significa che - un soggetto che si trova al livello di integrità X può leggere - solo oggetti allo stesso livello o - superiore (“assioma di integrità semplice”); - \item \textbf{Write Down:} un soggetto al livello di integrità X può + \item \textbf{No Read Down:} Questo significa che + un soggetto che si trova al livello di integrità X può leggere solo oggetti allo stesso livello o superiore (``assioma di integrità semplice''); + \item \textbf{No Write Up} un soggetto al livello di integrità X può scrivere solo oggetti allo stesso livello o di livello più basso (assioma di integrità * o Proprietà di semplice sicurezza); @@ -89,8 +89,7 @@ \subsection{Modello BIBA} ordini dai suoi superiori o parigrado e può imporre ordini solo ai suoi sottoposti o parigrado per evitare un cambiamento/danneggiamento nella missione da svolgere. -Da notare che \textit{Read Up} e \textit{Wite Down} sono l'opposto delle regole -\textit{Read Down}, \textit{Write Up} del modello Bell-LaPadula.\\ +Da notare che \textit{No Read Down} e \textit{No Write Up} sono l'opposto delle regole \textit{No Read Up}, \textit{No Write Down} del modello Bell-LaPadula.\\ È impossibile trasformare informazioni meno trusted in più trusted. L'obiettivo di tale modello è quello di evitare che il grado di fiducia di @@ -165,14 +164,14 @@ \subsection{Modello Clark-Wilson} così l'integrità; \end{itemize} -\paragraph{Esempio.}\ \\ +\paragraph{Esempio.}\ \begin{figure}[H] \centering \includegraphics[width=\textwidth, keepaspectratio]{capitoli/policy/imgs/clark_wilson.png} \end{figure} -Consideriamo il momento in cui il fornitore consegna la merce ad una specifica e +Consideriamo il momento in cui il fornitore consegna la merce ad una azienda e ciò è testimoniato dalla shipnote, ovvero la bolla di consegna. Una possibile organizzazione dell'impresa prevede che vi sia una persona addetta al magazzino che verifica se la merce ricevuta corrisponde a quella specificata nella bolla. @@ -311,11 +310,7 @@ \subsubsection{Come funziona?} risultare CDI. Il minimo di sicurezza richiesta comprende: \begin{itemize} - \item Integrità: i vincoli d'integrità esistono per proteggere IS da - maligni o accidentali modifiche - dei dati. Le regole possono essere definite su stati statici del db - o su transazioni (es. prima - di poter effettuare un modifica); + \item Integrità: i vincoli d'integrità esistono per proteggere IS da modifiche maligne o accidentali dei dati. Le regole possono essere definite su stati statici del db o su transazioni (es. prima di poter effettuare un modifica); \item Identificazione, autenticazione: prima di accedere a un sistema ogni utente deve essere identificato e autenticato per mantenerne traccia e per dargli @@ -333,7 +328,7 @@ \subsubsection{Regole di certificazione} \item \textbf{CR2} una TP deve trasformare un insieme di CDI da uno stato valido ad uno valido \begin{itemize} - \item CR2 definisce come “certificata” una relazione che + \item CR2 definisce come ``certificata'' una relazione che associa un insieme di CDI ad una TP; \item CR2 implica che una TP può corrompere una CDI se non è @@ -383,8 +378,7 @@ \subsubsection{Utenti e regole} \begin{itemize} \item \textbf{CR3} Le relazioni di permesso devono essere basate sulla separazione dei compiti. - \item \textbf{ER3} Il sistema deve autenticare ogni utente che vuole - utilizzare una TP. + \item \textbf{ER3} Il sistema deve autenticare ogni utente che utilizza una TP. \end{itemize} \subsubsection{Uso dei Log} @@ -407,14 +401,13 @@ \subsubsection{Trattamento di input non fidato} \item \textbf{CR5} Ogni TP che prende in input un UDI può eseguire solo trasformazioni valide, oppure nessuna trasformazione, per ogni possibile valore dell'UDI. - La trasformazione può quindi rifiutare il - UDI o trasformarlo in un CDI. + La trasformazione può quindi rifiutare l'UDI o trasformarlo in un CDI. \begin{itemize} \item Un possibile esempio: in un banca i numeri inseriti da tastiera sono UDI, i quali 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. + la validazione fallisce, la TP rigetta l'UDI. \end{itemize} \end{itemize} diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/introduzione.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/introduzione.tex index 0a21e5ed9..66d8eb34b 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/introduzione.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/policy/introduzione.tex @@ -5,7 +5,7 @@ aziendali per contrastare i rischi informatici. Si va a identificare tutte quelle regole che possono essere stabilite su un Server così che le workstation collegate vengano -"controllate" nella stessa +``controllate'' nella stessa maniera e per fare in modo che su di esse siano presenti le stesse caratteristiche. L'obiettivo è quello di garantire i tre goal della Sicurezza: @@ -16,19 +16,19 @@ violazione del sistema. Il sistema si muove da uno stato ad un altro. Ciò che deve fare la policy è fare in modo che questo -non assuma mai in stati non sicuri. Un sistema si dice “sicuro” quando ciò +non assuma mai stati non sicuri. Un sistema si dice ``sicuro'' quando ciò non accade mai. Quando un sistema permette ad un utente o ad un processo di entrare in uno stato non autorizzato -si dice che si è verificato un “security breach”. +si dice che si è verificato un ``security breach''. Sia X un set di entità e I un informazione: \begin{itemize} \item I ha riservatezza con rispetto a X se nessun membro di X può ottenere alcuna informazione su I; \item I ha integrità con rispetto a X se tutti i membri di X si fidano - di I. Le nozioni di “fiducia” e - “integrità” sono collegate. Se un sistema ha integrità, dobbiamo + di I. Le nozioni di ``fiducia'' e + ``integrità'' sono collegate. Se un sistema ha integrità, dobbiamo fidarci del fatto che il suo comportamento è corretto. Se I è una risorsa, la sua integrità implica che essa funzioni @@ -66,7 +66,7 @@ Un mezzo per ottenere l'integrità è la separazione dei compiti. Si deve fare in modo che tutte le operazioni compiute (transazioni) mantengano il sistema in uno -stato “consistente”. +stato ``consistente''. \paragraph{Availability.} @@ -78,37 +78,40 @@ specifico di larghezza di banda). \end{itemize} +\paragraph{Elementi base di una policy:} +Gli elementi base di una policy sono 3, ovvero: +\begin{itemize} + \item Subject: entità in grado di accedere ad una risorsa; + \item Object: risorsa a cui vuole accedere l'entità e il cui accesso è regolamentato; + \item Access right: descrive le modalità in cui una entità può accedere una risorsa; +\end{itemize} + \paragraph{La policy e i suoi meccanismi: } La policy descrive ciò che è permesso e cosa no, i meccanismi, -invece, controllano come questa viene implementata. Chiaramente gli utenti devono verificarsi -della policy, ma anche dei meccanismi utilizzati. -Le policy prese in considerazione per il controllo sugli accessi sono: +invece, controllano come questa viene implementata. Chiaramente gli utenti devono verificare sia policy che meccanismi utilizzati. Le policy prese in considerazione per il controllo sugli accessi sono: \begin{itemize} - \item Discretionary Access Control (DAC): il proprietario determina i - diritti di accesso. Solitamente sono identity-based access control - (IBAC), ovvero il proprietario indica anche quali altri utenti - possono avere l'accesso; - \item Mandatory Access Control (MAC): policy più restrittive. Stabiliscono - a priori quali sono i comportamenti da evitare e quelli permessi. - Ciò non viene specificato da chi crea la risorse, ma anche dalle - regole generali che vengono messe in atto, per esempio quelle - aziendali; - \item Originator Controlled Access Control (ORCON): policy dove colui che - assegna i diritti è il creatore. I possessori dei file non detengono - diritti e non possono cederli a loro volta; - \item Role Based Access Control (RBAC): usate in ambito commerciale per la - gestione delle risorse a livello amministrativo e aziendale. Quando + \item Discretionary Access Control (\textbf{DAC}): il proprietario determina i diritti di accesso. Solitamente sono identity-based access control (IBAC), ovvero il proprietario indica anche quali altri utenti possono avere l'accesso. E' definita ``discrezionale'' perché un utente può avere diritti di accesso che gli consentono, di sua spontanea volontà, di consentire a un altro utente l'accesso alla risorsa; + \item Mandatory Access Control (\textbf{MAC}): policy più restrittive. Stabiliscono a priori quali sono i comportamenti da evitare e quelli permessi. Ciò non viene specificato da chi crea la risorse, ma dalle regole generali che vengono messe in atto, per esempio quelle aziendali. In particolare controlla l'accesso in base al confronto tra le etichette di sicurezza (che indicano quanto sono sensibili o critiche le risorse del sistema) e i permessi di sicurezza (che indicano a quali determinate risorse possono accedere gli utenti del sistema). Questa politica è definita obbligatoria (``mandatory'') perché un'entità che ha il permesso per accedere a una risorsa NON può, di sua spontanea volontà, consentire a un altro utente di accedere a quella risorsa; + \item Originator Controlled Access Control (\textbf{ORCON}): policy dove colui che assegna i diritti è il creatore. I possessori dei file non detengono diritti e non possono cederli a loro volta. Il creatore permette che il file sia diffuso a soggetti terzi con le seguenti restrizioni: + \begin{itemize} + \item il file non può essere rilasciato ad altri soggetti senza il permesso del creatore; + \item ogni copia del file deve avere le stesse restrizioni; + \end{itemize} + \item Role Based Access Control (\textbf{RBAC}): controlla l'accesso in base ai ruoli che gli utenti hanno all'interno del sistema e alle regole che stabiliscono quali accessi sono consentiti agli utenti in determinati ruoli. Quando si definisce una policy si devono sempre tenere presenti: \begin{itemize} \item Gli utenti; \item I ruoli che essi ricoprono: utente, utente segreto, sistemista, utente negligente.. \item Le operazioni che possono essere compiute o no: leggere, - scrivere, “downgrade”, cambio password... + scrivere, ``downgrade'', cambio password... \item Le modalità con cui vietare o consentire determinate operazioni: obbligo, permesso, divieto, discrezionalità.. \end{itemize} + + \item Attribute-based access control (\textbf{ABAC}): controlla l'accesso in base sia agli attributi dell'utente che a quelli della risorsa a cui vuole accedere. + \end{itemize} \paragraph{Matrice di Controllo degli Accessi:} @@ -119,6 +122,7 @@ da parte di un sistema operativo o da un sistema di gestione di database) è quello di una \textbf{Matrice di Accesso} (concetto inizialmente formulato da Lampson).\\ + Una tipica implementazione di questo schema consiste nell'avere: \begin{itemize} \item in una dimensione della matrice \textbf{i soggetti identificati} che @@ -148,13 +152,13 @@ \caption{Esempio di Matrice di Controllo degli Accessi.} \end{figure} -\noindent Nel caso in cui volessi avere accesso ad un file che non c’è, ci +\noindent Nel caso in cui volessi avere accesso ad un file che non c'è, ci sarebbe il file safe default di sistema, il default deve essere sempre safe. \\ Esistono anche altri metodi per mappare gli accessi (\textbf{più efficienti rispetto alle matrici}), come le \textbf{Access Control List} e le \textbf{Capability List}. Rispetto alle Access Control Matrix sono meno costose perché non contengono coppie riga/colonna vuote e di conseguenza inutili. Sono utilizzate -in genere per mappare appunto l’Access Control Matrix. +in genere per mappare appunto l'Access Control Matrix. \begin{figure}[H] \centering diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/assessment.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/assessment.tex index 68f18a30a..f15215cdf 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/assessment.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/assessment.tex @@ -1,6 +1,6 @@ \section{Risk Assessment} -Il processo di “\textit{Risk Assessment}” è usato per determinare l'ampiezza +Il processo di ``\textit{Risk Assessment}'' è usato per determinare l'ampiezza delle potenziali minacce ad un sistema IT ed identificare tutte le possibili contromisure per ridurre o eliminare tali voci di rischio. Vengono identificati: @@ -10,7 +10,7 @@ \section{Risk Assessment} (macchinari, merci, ma anche il database o la rete) che deve essere protetto; \item \textbf{minacce}: possibili attacchi, quindi non ancora avvenuti; - \item \textbf{vulnerabilità}; + \item \textbf{vulnerabilità}: falle di sicurezza che portano al bypass delle policy; \item \textbf{contromisure}: da implementare per evitare le vulnerabilità; \end{itemize} diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/atree.png b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/atree.png index 8c127c770..68369b425 100644 Binary files a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/atree.png and b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/atree.png differ diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/cp-nets_con_defence_tree.PNG b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/cp-nets_con_defence_tree.PNG new file mode 100644 index 000000000..4dd28cbca Binary files /dev/null and b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/cp-nets_con_defence_tree.PNG differ diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/cp-nets_example.PNG b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/cp-nets_example.PNG new file mode 100644 index 000000000..d1af9f882 Binary files /dev/null and b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/cp-nets_example.PNG differ diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/dtree.png b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/dtree.png index f3c5f62cc..948767023 100644 Binary files a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/dtree.png and b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/imgs/dtree.png differ diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/intro.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/intro.tex index 9e513e8d0..594451d73 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/intro.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/intro.tex @@ -1,4 +1,4 @@ -Il processo di “\textit{Risk Management}” è l'insieme di attività coordinate +Il processo di ``\textit{Risk Management}'' è l'insieme di attività coordinate per gestire un'organizzazione con riferimento ai rischi. Tipicamente include l'identificazione, la misurazione e la mitigazione delle varie esposizioni al rischio. @@ -9,7 +9,7 @@ (\textit{riservatezza}) o di perdita di dati rilevanti archiviati tramite mezzi computerizzati (\textit{integrità}). Per operare su questi rischi è stata introdotta la -“\textit{Information Security Risk Management}”. +``\textit{Information Security Risk Management}''. Va ricordato che Identificazione e Misurazione sono racchiusi nella Risk Assessment. diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/mitigation.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/mitigation.tex index 7adce5134..0abd4479f 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/mitigation.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/risks/mitigation.tex @@ -1,10 +1,10 @@ \section{Risk Mitigation} -Nel processo di “\textit{Risk Mitigation}” vengono analizzate le contromisure +Nel processo di ``\textit{Risk Mitigation}'' vengono analizzate le contromisure raccomandate dal team di assessment e poi selezionate e implementate quelle che presentano il miglior rapporto costi/benefici. -Solitamente si adotta la modalità degli “\textbf{Attack Tree}” +Solitamente si adotta la modalità degli ``\textbf{Attack Tree}'' (approcci qualitativi). Più nel dettaglio distinguiamo: @@ -13,7 +13,7 @@ \section{Risk Mitigation} realizzarsi all'interno di un sistema. Lo scopo è quello di individuare le possibili minacce e il livello di rischio associato ad ogni - risorsa che compone il sistema. Vengono chiamati “Attack Tree” perché + risorsa che compone il sistema. Vengono chiamati ``Attack Tree'' perché l'analisi dei possibili attacchi viene effettuata per mezzo della costruzione di alberi. \item Approcci \textbf{quantitativi} (Indici economici): Quantificazione di @@ -57,7 +57,7 @@ \subsection{Attack Tree} \caption{Questa immagine rappresenta un Attack Tree.} \end{figure} -Gli alberi di difesa (\textbf{Defense Tree}) sono un'estensione degli +Gli alberi di difesa (\textbf{Defence Tree}) sono un'estensione degli Attack Trees (nodi quadrati). Si costruiscono per capire quali sono le possibili contromisure da adottare. Considerando tutte queste possibilità di un eventuale attacco, @@ -71,7 +71,37 @@ \subsection{Attack Tree} \begin{figure}[H] \centering \includegraphics[width=8cm, keepaspectratio]{capitoli/risks/imgs/dtree.png} - \caption{Questa immagine rappresenta un Defense Tree.} + \caption{Questa immagine rappresenta un Defence Tree.} +\end{figure} + +\subsection{Cp-nets} +Le conditional preference networks, dette anche cp-nets, sono delle rappresentazioni grafiche usate per esprime un ordine di preferenza.\\ + +Per capire meglio il concetto riportiamo subito un esempio (Figura~\ref{fig:cp-nets_example}). Poniamo il caso che siamo in un ristorante e che non sappiamo quali piatti sono disponibili e ci vogliamo affidare al cameriere su cosa mangiare. Utilizzando solo una frase siamo in grado di esprimere una preferenza condizionale su due variabili, in questo caso il piatto D e il vino W. Per ogni variabile dell'insieme di variabili, l'utente può specificare la variabile genitore che può influenzare la sua preferenza: nel nostro esempio D è genitore di W perché il tipo di piatto influenza la scelta del vino. + +\begin{figure}[H] + \centering + \includegraphics[width=11cm, keepaspectratio]{capitoli/risks/imgs/cp-nets_example.png} + \caption{Esempio utilizzo cp-nets.} + \label{fig:cp-nets_example} +\end{figure} + +Come visto in Figura~\ref{fig:cp-nets_example}, la preferenza va dalla condizione ``meno preferita'' a quella ``preferita'' seguendo un ordine o da sinistra verso destra o dall'alto verso il basso.\\ + +Sfruttando lo stesso concetto le cp-nets vengono usate in combinazione ai Defence Tree in maniera tale che: +\begin{itemize} + \item I \emph{Defence Tree} ci permettono di determinare, in modo qualitativo, le strategie di attacco che un attaccante può seguire per danneggiare + un sistema, le diverse azioni che compongono ogni attacco e le misure di sicurezza che possono essere adottate nel sistema. + \item Le \emph{cp-nets} vengono poi usate per determinare l'ordine di preferenza dell'amministratore di sistema nella selezione delle contromisure da adottare per ogni singolo nodo di attacco nel Defence Tree. +\end{itemize} + +Di seguito possiamo vedere un reale esempio di utilizzo delle cp-nets con i Defence Tree. In questo caso l'attacco \emph{\textbf{$a_4$}} è meno pericoloso dell'attacco \emph{\textbf{$a_3$}} che è meno pericoloso dell'attacco \emph{\textbf{$a_5$}} e così via. Poi, per ogni attacco, andiamo a dare un ordine di preferenza alle relative contromisure adottabili. Ad esempio, per l'attacco \emph{\textbf{$a_1$}} avremo che la contromisura \emph{\textbf{$c_1$}} sarà meno preferita rispetto alla contromisura \emph{\textbf{$c_2$}} ma che a sua volta sarà meno preferita della contromisura \emph{\textbf{$c_3$}}. + +\begin{figure}[H] + \centering + \includegraphics[width=12cm, keepaspectratio]{capitoli/risks/imgs/cp-nets_con_defence_tree.png} + \caption{Esempio utilizzo cp-nets con Defence Tree.} + \label{fig:cp-nets_con_defence_tree} \end{figure} \subsection{Indici Economici} diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/security_design/principi_fondamentali.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/security_design/principi_fondamentali.tex index 2f3324475..7e55ab974 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/security_design/principi_fondamentali.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/security_design/principi_fondamentali.tex @@ -1,6 +1,6 @@ \section{Principi Fondamentali} -I primi 8 sono stati definiti da un docente di nome +I principi fondamentali di progettazione della sicurezza sono una serie di linee guida che consentono agli sviluppatori di creare sistemi protetti. In totale sono 13 di cui i primi 8 sono stati definiti da un docente di nome Saelzer in un articolo del 1975. Gli altri sono stati aggiunti dai ricercatori nel tempo. Nello specifico: @@ -10,7 +10,7 @@ \section{Principi Fondamentali} Tenere il sistema più semplice possibile nel progetto, nell'implementazione, per quanto riguarda il numero di operazioni, le interazioni con altre componenti e addirittura nella -specifica. “Semplice” +specifica. ``Semplice'' significa che ci sono meno cose da controllare e quindi in caso di errori è più facile identificarli e correggerli. @@ -23,8 +23,8 @@ \section{Principi Fondamentali} \begin{itemize} \item \textbf{KISS} è un acronimo usato in progettazione, che sta per - “\textit{Keep It Simple, Stupid}”, ossia - "\textit{rimani sul semplice, stupido}". + ``\textit{Keep It Simple, Stupid}'', ossia + ''\textit{rimani sul semplice, stupido}''. In riferimento al codice sorgente di un programma significa non occuparsi delle ottimizzazioni fin dall'inizio, ma cercare invece di mantenere uno stile di @@ -37,8 +37,8 @@ \section{Principi Fondamentali} possono potenzialmente confondere l'utente; \item \textbf{Worse is better}: la qualità non è necessariamente funzionale; - \item \textbf{YAGNI}: l'espressione “\textit{you aren't gonna need it}”, - dall'inglese "\textit{non ne avrai bisogno}", + \item \textbf{YAGNI}: l'espressione ``\textit{you aren't gonna need it}'', + dall'inglese ``\textit{non ne avrai bisogno}'', in ingegneria del software si riferisce a un principio secondo cui un programmatore non dovrebbe sviluppare software che implementi funzionalità non esplicitamente richieste.\footnote{Un esempio è la vulnerabilità @@ -65,8 +65,7 @@ \section{Principi Fondamentali} Mentre i prodotti fail-safe sono sbloccati quando viene tolta la corrente (cioè viene applicata la corrente per bloccare la porta), i prodotti fail-secure sono bloccati quando viene tolta la corrente -(cioè viene applicata la corrente per sbloccare la porta) -In sintesi i sistemi: +(cioè viene applicata la corrente per sbloccare la porta). In sintesi, i sistemi: \begin{itemize} \item \textbf{Fail-secure}: vige la default-deny nei firewall. @@ -106,12 +105,12 @@ \section{Principi Fondamentali} file viene considerato un privilegio, come lo stesso accesso alla rete. Vanno inoltre distinti lettura e scrittura. -Vige anche il principio +Vige anche il principio: \begin{itemize} - \item della “separazione funzionale”: persone diverse, pur avendo diversi + \item della ``separazione funzionale'': persone diverse, pur avendo diversi compiti, devono cooperare; - \item del “controllo duale”. + \item del ``controllo duale''. \end{itemize} \paragraph{Least privilege} @@ -166,11 +165,10 @@ \section{Principi Fondamentali} tecnologia e gli aspetti operativi dei sistemi informativi. \paragraph{Least astonishment} -Un programma o un'interfaccia utente dovrebbe sempre rispondere nel modo meno -probabile per stupire l'utente. +Un programma o un'interfaccia utente dovrebbe sempre comportarsi nel modo in cui la maggior parte degli utenti si aspetta che si comporti, senza quindi stupire o sorprendere gli utenti. -\paragraph{Defense in Depth} -La “\textit{difesa in profondità}” o \textit{Defense in Depth} è +\paragraph{Defence in Depth} +La ``\textit{difesa in profondità}'' o \textit{Defense in Depth} è l'approccio alla sicurezza delle informazioni che prevede il raggiungimento di una corretta postura di sicurezza attraverso l'utilizzo coordinato e combinato di molteplici contromisure di sicurezza. @@ -178,9 +176,9 @@ \section{Principi Fondamentali} categorie di elementi: le \textit{persone}, la \textit{tecnologia} e le \textit{modalità operative}. La ridondanza e la distribuzione delle contromisure possono essere sintetizzate in due -frasi: \textit{“difesa in differenti posizioni}” e -“\textit{difesa a differenti livelli}” -(“Defense in Multiple places”, “Layered Defenses”). +frasi: \textit{``difesa in differenti posizioni}'' e +``\textit{difesa a differenti livelli}'' +(``Defense in Multiple places'', ``Layered Defenses''). Nel caso che un attacco abbia successo, che tradotto in termini di difesa consiste nel fallimento di un meccanismo di sicurezza, altri meccanismi di sicurezza possono intervenire per consentire un'adeguata protezione dell'intero @@ -188,17 +186,17 @@ \section{Principi Fondamentali} \paragraph{Confinement problem} Uno dei principali problemi che si può presentare in un sistema in ci sono più -utenti ed un server che elabora le richieste, è il \textit{“confinement problem}”: +utenti ed un server che elabora le richieste, è il \textit{``confinement problem}'': evitare che il server lasci trapelare informazioni che l'utente ritiene confidenziali. -Una possibile soluzione è rappresentata dall’\textit{isolamento totale}, +Una possibile soluzione è rappresentata dall'\textit{isolamento totale}, in cui i processi non possono comunicare tra loro, né osservare gli altri. Ciò evita la fuoriuscita di informazioni dal sistema, ma è irrealizzabile se i processi usano delle risorse osservabili. In tal caso, si potrebbe aggirare il problema utilizzando i \textbf{covert channel}, i quali sfruttano dei percorsi -nati per compiere altre operazioni diverse dalla comunicare, per fare invece -delle comunicazioni in realtà proibite. Un’altra -soluzione, potrebbe essere quella che prevede l’utilizzo di \textbf{sandbox}, +nati per compiere altre operazioni diverse dalla comunicazione, per fare invece +delle comunicazioni in realtà proibite. Un'altra +soluzione, potrebbe essere quella che prevede l'utilizzo di \textbf{sandbox}, ossia scatole dove viene confinata l'esecuzione di processi e su cui sono vigenti delle policy di sicurezza restrittive a piacere. \ No newline at end of file diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/security_design/trust_network.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/security_design/trust_network.tex index 421aaf3fe..375cae97d 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/security_design/trust_network.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/security_design/trust_network.tex @@ -1,3 +1,5 @@ +\newpage + \section{Trust Network Brainstorming} Ogni sistema di sicurezza dipende dalla fiducia, in una forma o nell'altra, @@ -6,11 +8,7 @@ \section{Trust Network Brainstorming} e mitigare il rischio in determinate condizioni. Quale forma di fiducia applicare in una determinata circostanza è generalmente dettata dalla politica aziendale. -Le \textbf{trust network} (reti di fiducia) consistono in ramificazioni di -connessioni interpersonali costituite principalmente da forti legami, -all'interno dei quali le persone mettono a rischio risorse e imprese di -valore, conseguenti, a lungo termine, a rischio di illeciti, errori o fallimenti -altrui. +Le \textbf{trust network} (reti di fiducia) consistono in ramificazioni di connessioni interpersonali costituite principalmente da forti legami in cui una parte è disposta a dipendere da qualcuno, in una determinata situazione, con una sensazione di relativa sicurezza, anche se sono possibili conseguenze negative a causa del fallimento altrui. Le relazioni di fiducia consentono agli utenti di un dominio di accedere alle risorse di un altro dominio. I trust funzionano facendo sì che un dominio si affidi all'autorità dell'altro dominio per @@ -29,12 +27,12 @@ \section{Trust Network Brainstorming} \item asimmetria: la fiducia che detiene un utente verso un altro non deve essere necessariamente speculare; - \item indipendenza dal contesto. + \item i giudizi sono dipendenti dal contesto. \end{itemize} \paragraph{Semirings} viene utilizzata come struttura generica per il calcolo della -fiducia nelle reti fiduciarie (cioè pesate). I \textit{semirings} “bipolari” +fiducia nelle reti fiduciarie (cioè pesate). I \textit{semirings} ``bipolari'' permettono di considerare insieme fiducia e sfiducia e di avere così una composizione sicura delle reti trust (avviene una fusione critica ogni volta che due comunità basate sulla fiducia diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/sql_security/attacks.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/sql_security/attacks.tex index 6c1d6248e..f71072750 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/sql_security/attacks.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/sql_security/attacks.tex @@ -77,7 +77,7 @@ \subsection{Attack Types} \item \textbf{Commento di fine riga}: Dopo aver iniettato codice in un particolare campo, il codice legittimo che segue viene annullato attraverso l'uso di commenti di fine riga. Un esempio potrebbe - essere quello di aggiungere "\verb|--|" dopo gli input in modo che + essere quello di aggiungere ``\verb|--|'' dopo gli input in modo che le query rimanenti non siano trattate come codice eseguibile, ma come commenti. \item \textbf{Query piggybacked}: L'attaccante riesce ad aggiunge ed diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/sql_security/introduzione.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/sql_security/introduzione.tex index 882381601..96702255b 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/sql_security/introduzione.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/capitoli/sql_security/introduzione.tex @@ -2,7 +2,7 @@ \section{Introduzione} Negli ultimi anni il modello di Database Relazionale è diventato molto popolare ed ampiamente utilizzato da privati e aziende. -Per molte organizzazioni, è importante essere in grado di +Per molte organizzazioni è importante essere in grado di fornire a clienti, partner e dipendenti l'accesso alle informazioni da loro memorizzate. Ma tali informazioni possono essere prese di mira da minacce interne ed esterne, possono essere utilizzate impropriamente o modifiche da entità non autorizzate. Di conseguenza, la sicurezza @@ -15,7 +15,7 @@ \section{Introduzione} \item C'è un drammatico squilibrio tra la complessità dei moderni database (DBMS) e le tecniche di sicurezza usate per proteggere questi sistemi critici. Un DBMS è un software molto complesso e di grandi - dimensioni, che fornisce molte opzioni, che devono essere tutte ben + dimensioni, che fornisce molte opzioni che devono essere tutte ben comprese e poi protette per evitare violazioni dei dati. \item I database hanno un sofisticato protocollo di interazione chiamato \textit{Structured Query Language} (\textbf{SQL}), @@ -27,7 +27,7 @@ \section{Introduzione} non è sufficientemente formato per gestirne anche la sicurezza. \item La maggior parte degli ambienti aziendali consiste in una miscela eterogenea di piattaforme di database, piattaforme aziendali e OS, - quindi non avere un solo db o un solo tipo di sistema operativo + quindi non avere un solo DB o un solo tipo di sistema operativo rappresenta una problematica che crea un'ulteriore complessità per il personale. \item La crescente dipendenza dalla tecnologia cloud per ospitare parte o diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/frontmatter/main.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/frontmatter/main.tex index 6e8d190db..de80f3c7d 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/frontmatter/main.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/frontmatter/main.tex @@ -16,7 +16,9 @@ \vspace{8 em} \begin{center} - {\Huge Appunti Cybersecurity}\\ + {\Huge Appunti}\\ + \vspace{1 em} + {\Huge \textit{Cybersecurity}}\\ \vspace{5 em} {\Huge \textbf{Bistarelli}}\\ diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/main.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/main.tex index 4ad42437b..1427871e9 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/main.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/main.tex @@ -1,4 +1,5 @@ \documentclass[a4paper,12 pt]{report} +\usepackage[italian]{babel} \usepackage[T1]{fontenc} \usepackage[utf8]{inputenc} \usepackage{lmodern} @@ -13,7 +14,6 @@ % forza le footnote a stare il più in basso possibile \usepackage[bottom]{footmisc} - %% STILE LISTINGS \usepackage{xcolor} diff --git a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/quote/main.tex b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/quote/main.tex index e379d17b6..fe43b0cfc 100644 --- a/magistrale/Anno 1/Cybersecurity/latex/bistarelli/quote/main.tex +++ b/magistrale/Anno 1/Cybersecurity/latex/bistarelli/quote/main.tex @@ -9,9 +9,9 @@ \begin{center} \parbox{\longest}{% \raggedright{\LARGE\itshape% - "Oi, con quanto sentimento\\ + ``Oi, con quanto sentimento\\ defeco sul tuo naso,\\ - così che ti coli sul mento."\par\bigskip + così che ti coli sul mento.''\par\bigskip } \raggedleft\Large{Wolfgang Amadeus Mozart}\par% }