Merge pull request #254 from Polpetta/218-merge_9.1_e_9.2.1.5

Merge 9.1 and 9.2.1.5 and 80 columns

Author: Polpetta

res/sections/25-Les10052017.tex

@@ -2,33 +2,33 @@ \subsection{Segregation of duties}
 
 Questo concetto è molto importante.
 
-La \textit{conformità} è più importante della \textit{sicurezza} perché 
+La \textit{conformità} è più importante della \textit{sicurezza} perché
 bisogna essere conformi a degli standard.
 
-È importante, come già detto in precedenza, separare i vari 
-poteri tra le persone, in maniera tale da assicurarsi che non avvengano 
-``abusi di potere'' (es. l'amministratore di rete concede i diritti, ma 
-qualcuno deve autorizzare che il ruolo $x$ necessiti dei diritti. 
-L'amministratore implementa la concessione). 
-
-È importante anche che gli \textit{asset} vengano controllati. Solitamente gli 
-\textit{asset} sono fisici, ma nel settore IT possono essere immateriali (come 
-un file contente un disegno di un progetto per una architettura di rete). 
-Quindi è importante documentare le responsabilità. Si è responsabili quando 
-si verificano \textit{due condizioni:} quando si è nominati ufficialmente (tramite 
-una delega formale) o quando si hanno i poteri per implementare correttamente 
+È importante, come già detto in precedenza, separare i vari
+poteri tra le persone, in maniera tale da assicurarsi che non avvengano
+``abusi di potere'' (es. l'amministratore di rete concede i diritti, ma
+qualcuno deve autorizzare che il ruolo $x$ necessiti dei diritti.
+L'amministratore implementa la concessione).
+
+È importante anche che gli \textit{asset} vengano controllati. Solitamente gli
+\textit{asset} sono fisici, ma nel settore IT possono essere immateriali (come
+un file contente un disegno di un progetto per una architettura di rete).
+Quindi è importante documentare le responsabilità. Si è responsabili quando
+si verificano \textit{due condizioni:} quando si è nominati ufficialmente (tramite
+una delega formale) o quando si hanno i poteri per implementare correttamente
 quanto richiesto.
 
 \subsubsection{Personale}
 
 Dal punto di vista della sicurezza il personale è sempre l'anello debole.
 Il \textit{background check} dipende sempre in base alla mansione che
 dev'essere coperta. Questi controlli sono abbastanza sensibili.
-Se viene maneggiato denaro o \textit{asset} sicuramente è necessario eseguire 
-un \textit{background check} per assicurarsi la \textit{professionalità} e 
-l'\textit{affidabilità} della persona (anche essere coinvolti in una stupida 
-rissa potrebbe compromettere l'affidabilità di una persona). Di conseguenza, i 
-propri profili social dovrebbero essere sempre controllati in maniera tale da 
+Se viene maneggiato denaro o \textit{asset} sicuramente è necessario eseguire
+un \textit{background check} per assicurarsi la \textit{professionalità} e
+l'\textit{affidabilità} della persona (anche essere coinvolti in una stupida
+rissa potrebbe compromettere l'affidabilità di una persona). Di conseguenza, i
+propri profili social dovrebbero essere sempre controllati in maniera tale da
 non contenere contenuto non appropriato.
 
 Il \textit{monitoring} delle email è un problema ovunque, tranne negli USA:
@@ -46,8 +46,8 @@ \subsubsection{Personale}
 
 Il \textbf{mansionario} specifica cosa un impiegato deve fare.
 
-\textbf{Confidentiality agreement}: contratto in cui il lavoratore dichiara di 
-non divulgare nulla di quello su cui lavora l'azienda e indica anche un limite 
+\textbf{Confidentiality agreement}: contratto in cui il lavoratore dichiara di
+non divulgare nulla di quello su cui lavora l'azienda e indica anche un limite
 di tempo per cui l'impiegato non può svolgere un lavoro nello stesso campo.
 
 
@@ -76,11 +76,11 @@ \subsubsection{Personale}
 
 \subsubsection{Accordi tra terze parti}
 
-Definiscono le \textit{policy} di sicurezza relative alle informazioni e le 
-procedure per implementare le \textit{policy}; forniscono controlli per 
-proteggersi contro software malevolo. Pubblicano restrizioni per la copia e la 
-distribuzione delle informazioni, implementano procedure per determinare se 
-gli \textit{asset} sono stati compromessi e assicurano il ritorno o la 
+Definiscono le \textit{policy} di sicurezza relative alle informazioni e le
+procedure per implementare le \textit{policy}; forniscono controlli per
+proteggersi contro software malevolo. Pubblicano restrizioni per la copia e la
+distribuzione delle informazioni, implementano procedure per determinare se
+gli \textit{asset} sono stati compromessi e assicurano il ritorno o la
 distruzione dei dati al termine del rapporto lavorativo.
 
 \subsubsection{Riassunto dei controlli sul personale}
@@ -113,195 +113,20 @@ \part{Security Management}
 
 \chapter{COBIT, CMM}
 
-\section{CMM}
-\textbf{CMM} sta per \textit{Capability Maturity Model}. Si è capito che lo 
-sviluppo del software è cruciale nelle società che lo sviluppano, le quali 
-vengono mappate in 5 livelli dove ogni livello identifica la maturità di 
-un'azienda.
-I cinque livelli sono:
-\begin{enumerate}
-  \item \textbf{Initial:} si ``vive alla giornata''. Si è estremamente 
-  reattivi agli eventi che accadono e non è in atto alcun tipo di 
-  pianificazione/processo;
-  \item \textbf{Managed:} si ha ancora un approccio di tipo reattivo agli 
-  eventi che accadono, ma si comincia ad definire processi ed ad avere 
-  pianificazioni per i progetti;
-  \item \textbf{Defined:} si cominciano a definire processi anche per 
-  l'organizzazione in toto e si comincia ad avere un approccio proattivo ai 
-  problemi;
-  \item \textbf{Qualitatively Managed:} vengono applicate misurazioni e
-  metriche ai processi per poter controllarli e migliorarli continuamente;
-  \item \textbf{Optimized:} una volta che è in atto il miglioramento continuo 
-  dei processi che vengono a loro volta misurati tramite metriche l'azienda 
-  può puntare ad ottimizzarli il più possibile.
-\end{enumerate}
-Il CMM è stato superato dal CMMI \textit{Capability Maturity Model Integration}.
-
-
-Il \textbf{COBIT} è uno standard diverso.
-
-
-\subsection{Livello 0}
-
-Al livello iniziale si è come un pompiere: si corre continuamente a destra e a
-sinistra per risolvere eventuali problemi.
-
-\subsection{Livello 1 - Esecuzione informale}
-
-La progettazione della sicurezza è definita in maniera povera, i problemi di 
-sicurezza sono trattati in maniera reattiva: si reagisce 
-alla minaccia, portando prima o poi l'attacco a vincere. Non ci sono piani di 
-contingenza\footnote{I piani di contingenza sono dei piani che dettano le 
-azioni da compiere in caso si verificano delle situazioni d'emergenza.}. I 
-budget, la qualità, le funzionalità e i progetti vengono schedulati \textit{ad 
-hoc}. Non ci sono aree dei processi.
-
-\subsection{Livello 2 - Pianificato e Tracciato}
-
-Le procedure vengono definite a livello di progetto. La definizione, 
-pianificazione e le performance diventano de-facto standard da progetto a 
-progetto. Gli eventi vengono tracciati. Le funzionalità comuni includono: 
-pianificazione, disciplina, verifica e tracciamento delle performance.
-
-\subsection{Livello 3 - Ben definito}
-
-I processi di sicurezza sono standardizzati all'interno dell'organizzazione e 
-il personale viene addestrato per assicurarsi che abbia le conoscenze e le 
-skill necessarie. In aggiunta, le misure vengono basate su un processo 
-definito e gli audit tracciano le performance. Le funzionalità più comuni 
-includono: definire un processo standard, eseguire il processo definito e 
-coordinare le pratiche relative alla sicurezza.
-
-
-\subsubsection*{Documentazione delle policy}
-
-\begin{figure}[h!]
-        \begin{center}
-                \includegraphics[scale=0.4]{res/img/documentation_policy}
-        \end{center}
-        \caption{Documentazione delle policy.}
-\end{figure}
-
-\subsubsection{Esempi di policy}
-
-I \textbf{rischi} dovrebbero essere gestiti utilizzando dei controlli e delle 
-contromisure appropriate per raggiungere dei livelli accettabili a dei costi 
-accettabili. Il \textbf{monitoraggio} e le \textbf{metriche} dovrebbero essere 
-implementate, gestite e mantenute per fornire una certezza continua che tutte 
-le policy sulla sicurezza siano rispettate e i controlli oggettivi siano 
-riscontrati. Le \textbf{capacità di risposta ad incidenti} sono implementate e 
-gestite sufficientemente per garantire che gli incidenti non affliggano 
-materialmente la capacità dell'organizzazione di continuare le proprie 
-operazioni. 
-La \textbf{business continuity} e il \textbf{recovery plan} dovrebbero essere 
-sviluppati, manutenuti e testati in modo da assicurare la capacità 
-dell'organizzazione di proseguire con le proprie attività sotto tutte le 
-condizioni.
-
-
-Nota: una cattiva \textit{policy} fa riferimento alla tecnologia. Le
-\textit{policy} sono solamente linee guida.
-
-\subsubsection{Policy, procedure e standard}
-
-\paragraph*{Obiettivo di una policy:} descrive \textit{cosa} deve essere 
-soddisfatto.
-
-\paragraph*{Controllo della policy:} tecniche per raggiungere l'obiettivo, 
-suddivise in
-\begin{itemize}
-  \item \textbf{Procedure:} definiscono come la policy deve essere perseguita;
-  \item \textbf{Standard:} regola, metrica o vincolo specifico che implementa 
-  la policy.
-\end{itemize}
-
-\subsubsection{Definizioni della qualità}
-
-\paragraph*{Quality assurance:} assicurarsi che tutto lo staff stia seguendo i 
-processi della qualità definiti.
-
-\paragraph*{Controllo della qualità:} condurre test per validare che il 
-software è privo di difetti e corrisponde alle aspettative dell'utente.
-
-\subsection{Livello 4 - Metriche}
-
-Esistono degli obiettivi misurabili per la qualità della sicurezza, le misure 
-sono correlate agli obiettivi del business dell'organizzazione. Le 
-funzionalità comuni includono: stabilire degli obiettivi misurabili di qualità 
-e una gestione oggettiva delle performance (SLA).
-È tutto scritto e documentato: sono presenti politiche, procedure, standard e 7
-linee guida.
-
-\subsubsection{Metriche}
-
-Le metriche permettono ad auditor differenti di attestare che i programmi per 
-la sicurezza vengono attuati. Monitorare il raggiungimento di controlli 
-oggettivi è più importante che perfezionare le procedure di sicurezza.
-
-Senza metriche quantitative si lascia spazio alla soggettività.
-
-\begin{figure}[h!]
-        \begin{center}
-                \includegraphics[scale=1.5]{res/img/metriche}
-        \end{center}
-        \caption{Esempi di metriche per un'azienda.}
-\end{figure}
-
-\paragraph*{Metriche operazionali}
-
-Le metriche di tipo operazionale includono metriche su come eseguire
-un corretto \textit{patching} dei sistemi.
-
-Confrontare le metriche con quelle di altre aziende permette di capire quanto
-siamo un possibile \textit{target} per gli attaccanti.
-
-\paragraph*{Metriche di tipo strategico}
-
-Sono i piani legati al rischio, come il \textit{disaster recovery}.
-Il rapporto di audit è una metrica importantissima perché fa capire come 
-lavorano l'azienda e l'auditor.
-
-\paragraph*{Compliance interna}
-
-La conformità (\textit{compliance}) assicura la conformità con le policy 
-organizzative. Compliance e errore interno sono dati importanti perché 
-fanno capire all'azienda quanto è allineata con gli obiettivi strategici che 
-si è prefissata.
-
-
-\subsection{Livello 5 - Miglioramento continuo}
-
-Il miglioramento continuo parte dalle misure e dagli eventi sulla sicurezza.
-Vengono valutate nuove tecnologie e nuovi processi. Le funzionalità comuni
-includono: miglioramento delle capacità organizzative e dell'efficacia dei
-processi (ROI).
-
-Prima avere un cambio tecnologico di fondo era raro, oggi avviene ogni 3 anni. 
-Chi prende la tecnologia e la incorpora si prende la fetta di mercato.
-
-Le grandi società fanno \textit{scouting} di nuove tecnologie. Il vantaggio di
-essere un'azienda piccola è che si può essere aggressivi e investire, aiutando
-il movimento economico. Questo ci dice che aziende come Google non ci
-saranno per sempre. Non si è ancora capito a dove possa portare il cambiamento
-tecnologico. Un'altra area importante è l'intelligenza artificiale legata
-alla sicurezza.
-
-
-\section{COBIT \& COSO}
-
-\textbf{COSO} è un modello strategico per la governance dell'azienda. 
-Purtroppo è troppo complesso per un'azienda di dimensioni medio grandi e 
+Il \textbf{COSO} è un modello strategico per la governance dell'azienda,
+focalizzato sull'aspetto \textbf{finanziario}.
+Purtroppo è troppo complesso per un'azienda di dimensioni medio grandi e
 quindi è caduto in disuso.\\
 \newline
 \textbf{COBIT} è un insieme di raccomandazioni finalizzate alla \textit{
-governance} 
-del sistema IT a livello operativo.
-COBIT deriva da COSO ed è allineato con esso. In particolare il grafico in 
-Figura~\ref{fig:cobit:coso:relazione} mostra la relazione tra COSO e COBIT
-\footnote{Esistono manuali gratuiti 
-riguardo COBIT, che spaziano dal livello \textit{entry} fino a quelli più 
-avanzati. Questi manuali sono consigliati a chi vuole approcciarsi a questo 
-ambiente lavorativo. Al seguente link per esempio è possibile trovare un 
+governance}
+del sistema IT a livello \textbf{operativo}.
+COBIT deriva da COSO ed è allineato con esso. In particolare il grafico in
+Figura~\ref{fig:cobit:coso:relazione} mostra la relazione tra COSO e
+COBIT\footnote{Esistono manuali gratuiti
+riguardo COBIT, che spaziano dal livello \textit{entry} fino a quelli più
+avanzati. Questi manuali sono consigliati a chi vuole approcciarsi a questo
+ambiente lavorativo. Al seguente link per esempio è possibile trovare un
 manuale riguardo COBIT 4.1:  \url{https://www.isaca.org/Italian/Documents/
 CobiT-41-Italian.pdf}}.
 
@@ -313,7 +138,7 @@ \section{COBIT \& COSO}
         \label{fig:cobit:coso:relazione}
 \end{figure}
 
-\subsection{COBIT}
+\section{COBIT}
 \label{COBIT}
 
 Il COBIT è suddiviso in quattro domini:
@@ -325,25 +150,25 @@ \subsection{COBIT}
 \end{enumerate}
 Ognuno dei 34 processi del COBIT è assocciato ad uno di questi domini.
 
-\subsubsection{Pianificazione e organizzazione}
+\subsection{Pianificazione e organizzazione}
 
-In un'azienda IT è importante definire un piano strategico per l'IT. Si è 
-passati dall'avere un insieme di applicazioni centralizzate ad architetture 
-distribuite \textit{cloud}-centriche. Chi ha previsto queste innovazioni ieri, 
+In un'azienda IT è importante definire un piano strategico per l'IT. Si è
+passati dall'avere un insieme di applicazioni centralizzate ad architetture
+distribuite \textit{cloud}-centriche. Chi ha previsto queste innovazioni ieri,
 oggi sta guadagnando molto.
 
 L'\textit{information architecture} si focalizza su come viene distribuita
 l'informazione, su come viene distribuito il dato e su come viene aggiunta
 informazione al dato.
 
-La tendenza tecnologica è quella di andare verso un IT decentralizzato. La 
-manutenzione è importante ed è quindi altrettanto importante capire che una 
-rivisitazione dei costi IT non è possibile che venga eseguita a costo 0. I 
-processi messi in piedi sono molti importanti. La comunicazione è fondamentale 
-ed è un difetto di informatici e ingegneri. La non-comunicazione fa appassire 
-le idee\footnote{Perla del professore: \textbf{una buona idea comunicata bene 
-ottiene molto di più di un'idea eccellente comunicata male.}} e questo viene 
-aggravato dall'inerzia che ha una grande azienda, in quanto un gran numero di 
+La tendenza tecnologica è quella di andare verso un IT decentralizzato. La
+manutenzione è importante ed è quindi altrettanto importante capire che una
+rivisitazione dei costi IT non è possibile che venga eseguita a costo 0. I
+processi messi in piedi sono molti importanti. La comunicazione è fondamentale
+ed è un difetto di informatici e ingegneri. La non-comunicazione fa appassire
+le idee\footnote{Perla del professore: \textbf{una buona idea comunicata bene
+ottiene molto di più di un'idea eccellente comunicata male.}} e questo viene
+aggravato dall'inerzia che ha una grande azienda, in quanto un gran numero di
 persone si muovono lentamente tra loro.
 
 Anche le risorse IT sono importanti: non serve più solo prendere ``quello
@@ -369,7 +194,7 @@ \subsubsection{Pianificazione e organizzazione}
 
 \end{itemize}
 
-\subsubsection{Acquisizione e implementazione}
+\subsection{Acquisizione e implementazione}
 
 \begin{itemize}
 \item AI1: identificare soluzioni automatizzate;
@@ -382,15 +207,15 @@ \subsubsection{Acquisizione e implementazione}
 \item AI7: installare e certificare le soluzioni e le modifiche.
 \end{itemize}
 
-\subsubsection{Erogazione e assistenza}
+\subsection{Erogazione e assistenza}
 
 Questo dominio si occupa dell'organizzazione effettiva dei servizi,
 i controlli della disponibilità rispetto agli SLA e la sicurezza del
 servizio stesso.
-Quando si hanno servizi di diverse parti i \textit{Service Level 
+Quando si hanno servizi di diverse parti i \textit{Service Level
 Agreement} (SLA) sono fondamentali. Gestione e capacità sono concetti diversi.
-Quando si ha settato un'organizzazione il limite estremo è la capacità 
-ottimale (è quando tutti lavorano al 100\%, che è impossibile). Da qui bisogna 
-capire dove si è e quanto ce n'è, e questo viene detto \textit{capacity}. 
-Siccome è molto difficile per aziende grosse si guardano gli indicatori 
+Quando si ha settato un'organizzazione il limite estremo è la capacità
+ottimale (è quando tutti lavorano al 100\%, che è impossibile). Da qui bisogna
+capire dove si è e quanto ce n'è, e questo viene detto \textit{capacity}.
+Siccome è molto difficile per aziende grosse si guardano gli indicatori
 finanziari.