Appunti di Software CyberSecurity, Appunti di Sicurezza Dei Sistemi Informativi

Scarica Appunti di Software CyberSecurity e più Appunti in PDF di Sicurezza Dei Sistemi Informativi solo su Docsity!

A.A. 2021/

Software Cyberse-

curity

Appunti

GALEAZZI MARGHERITA

UNIVPM

Sommario

• Introduzione
  • Cyber Security Framework
  • La legge del rischio informatico ideale
  • Le domande fondamentali
    • Chi?
    • Perché?
    • Cosa?..........................................................................................................................................................
    • Quando?
    • Dove?
    • Quanto?
  • Gestione del rischio – Risposta ed Identificazione del rischio
  • Approccio alla mitigazione del Cyber-rischio
  • GDPR- Regolamento Generale per la Protezione dei Dati
• Modelli formali
  • Blueprint for a science of cybersecurity
  • Una breve introduzione alla probabilità......................................................................................................
    • La legge dei grandi numeri Borel
    • La probabilità soggettiva
    • La probabilità condizionale......................................................................................................................
    • Approccio frequentista ed approccio baynesiano
    • Probabilità a priori e a posteriori.............................................................................................................
    • Recall e Precision
    • Un esempio concreto
• Terminologia
  • System Dependability
  • Come si ottiene la dependability?
    • Costi della dependability
  • Security VS Privacy.......................................................................................................................................
  • Altri termini
  • Security Policies
    • La triade CIA.............................................................................................................................................
    • La triade AAA
    • Altre politiche di dependability
  • Meccanismi di controllo
    • Tecniche di difesa
    • Tecniche di reliability
  • Gli attacchi informatici
    • Le componenti di un attacco
    • Il workflow di un attacco
• Ingegneria del software
  • Metodologia di progettazione
  • Una prospettiva filosofica............................................................................................................................
  • Concetti chiave della sicurezza informatica
  • I diagrammi 𝑖 ∗.............................................................................................................................................
    • 𝑖 ∗ modellazione
    • Modellazione delle dipendenze strategiche
    • Modello Razionale
  • Dependable Software Engineering
  • System Dependability
    • Il buono, il brutto e il cattivo
  • Faults, errors and failures
    • Vulnerabilità
  • Software security engineering.....................................................................................................................
  • Requirement engineering............................................................................................................................
    • Errori durante l’ingegnerizzazione dei requisiti
• Sistemi a transizione di stato
  • Models Based on State Representation
    • Spazio di stato e variabili di stato
    • Sistema di transizione di stato con etichette e con osservazioni:
  • Un esempio: la funzione di login
  • NFA-DFA Equivalenza
  • Modellazione con concorrenza
    • Come si può modellare la concorrenza?
• Modelli Markoviani..........................................................................................................................................
  • Processi Markviani a tempo discreto
  • Un primo esempio
    • Probabilità di una traccia (o traiettoria)
  • Distribuzione della transizione di stato Θ𝑖
  • Distribuzione degli stati di equilibrio
    • Gli autovalori e gli autovettori sinistri
    • Distribuzione degli stati di equilibrio
    • Esempio
    • Esempio autospazio infinito
  • Distribuzione stazionaria, limitata dello spazio di stato
    • Esempio: distribuzione stazionaria
    • Distribuzione stazionaria, limitata dello spazio di stato
    • Esempio
• Prism
  • La sintassi.....................................................................................................................................................
    • Tipo di modello
    • Esempio: Login Function n.1....................................................................................................................

Introduzione

Cyber Security Framework

Alcuni anni fa il NST (National Institute of Standard Technology), ha costruito questo framework, ovvero una

serie di linee guida in campo di Cyber Security.

Il framework è composto da 5 aree: queste aree sono:

• Identificazione ( Identify ) → consiste nell’identificazione dei rischi, saperli valutare, consistono quindi

in una serie di linee guida su come valutare i rischi;

• Protezione ( Protect ) → ovvero una serie di line guida su come proteggere un’infrastruttura informa-

tica e quindi evitare di subire un attacco informatico;

• Rilevamento ( Detect ) → si parte dal presupposto che un attacco informatico possa comunque avve-

nire, nonostante tutte le nostre misure di prevenzione; quindi, bisogna avere degli strumenti per

accorgersi se nonostante tutto c’è un attacco informatico (strumenti di rilevamento);

• Risposta ( Respond ) → nel momento in cui ci accorgiamo che c’è un attacco informatico dobbiamo

predisporre una risposta pronta ed adeguata;

• Ripristino ( Recover ) → una volta che si è in qualche modo risposto all’attacco (eliminato/bloccato)

informatico, si devono riportare i sistemi alle normali condizioni di funzionamento.

Il NST è un ente che appartiene al dipartimento del commercio degli Stati Uniti che si occupa di defi-

nire gli standard e linee guida un po' su tutti gli aspetti che risultano di interesse per la vita economica

degli Stati Uniti e quindi di conseguenza aspetti che interessano la vita economica di tutto il mondo

visto che le attività sono pressappoco sempre le stesse.

Identify

Asset

Management

Business

Envrionment

Governance

Risk

Assessment

Risk

Management

Strategy

Protect

Access Control

Awareness and

Training

Data Security

Info Protection

Process and

Procedures

Maintenance

Protective

Technology

Detect

Anomalies and

Events

Security

Continuous

Monitoring

Detection

Processes

Respond

Response

Planning

Communicatio

ns

Analysis

Mitigation

Improvements

Recover

Recovery

Planning

Improvements

Communicatio

ns

Va notato che le vulnerabilità non sono solo dal punto di vista tecnologico, nella scrittura del software io

quelle posso ridurre ma permangono le altre.

L’unità di misura del rischio sono i soldi, ovvero la perdita in campo monetario che un rischio potrebbe gene-

rare.

Le domande fondamentali

Anche nell’analisi del rischio informatico le domande da porsi sono sempre e medesime. È sono quelle che si

pose San Tommaso D’Aquino nella sua Summa Theologiae. Ovvero:

• Chi?
• Cosa?
• Quando?
• Dove?
• Perché?
• Quanto?
• Come?
• A che scopo?

Per valutare i rischi bisogna quindi porsi tutte queste domande.

Cyber Risk

Cyber Incident Probability

Minaccia

Consumatori

scontenti

Errore umano

Azioni dei fornitori

Hacktivism

Crimine

Sabotaggio

Spionaggio

industriale

Terrorismo

Azioni di stato

Misure di forza

x

Vulnerabilità

Persone e Culture

Processi e

Organizzazioni

Tecnologie e

infrastrutture

x

Cyber Incident Impact

Beni a rischio

Beni non

tangibili

• proprietà

intellettuale

• reputazione
  • conformità

Beni tangibili

• finanziari
  • fisici
• sistemi

produttivi

• infrastrutture

Beni

"maggiori"

• vita e salute
  • libertà civili
    • privacy

individuale

x

Perdita

Confidenzialità

Integrità

Disponibilità

Autenticità

Assicurazione

Responsabilità

Sicurezza

Affidabilità

Resilienza

Chi?

A discapito di quanto ci viene

fatto credere la maggior parte

degli attacchi informatici parte

dagli Stati Uniti e dall’Alaska.

Perché?

Perché vengono compiuti gli attacchi informatici? In un primo momento gli attacchi erano delle challenge,

ovvero si voleva dimostrare al mondo di essere in grado di hackerare un sistema (un esempio di quanto

appena detto è la creazione del primo WORM), successivamente però, sono subentrate ulteriori motivazioni,

quali:

• Vandalismo (per vendetta o per hacktivismo);
• Scopi economici (mercato nero dei dati, Ransom o spionaggio industriale);
• Scopi politici (es. influenzare le campagne elettorali).

Riguardo agli scopi economici, si effettua l’hackeraggio dei dati perché questi sul mercato nero hanno una

loro quotazione, ovvero se si vuole comprare un determinato tipo di dato si deve pagare per il suo valore; la

tabella sottostante riporta la quotazione dei dati sul mercato nero nel dicembre 2020.

Tipo di dato Quotazione

Dettagli delle carte di credito Da 5 a 16 €

Scansioni di patenti Da 4 a 21 €

Scansioni di passaporti Da 4 a 13 €

Servizi di sottoscrizione Da 0,40 a 7 €

Dati identificativi (Nome completo, data di nascita,

email, numero di cellulare)

Da 0,40 a 8 €

Selfie con documenti (passaporto, patente) Da 33 a 50 €

Cartelle cliniche Da 0,84 a 25 €

Conti bancari Dal 1% al 10% del valore del conto

Conti PayPal Da 42 a 418 €

85%

2%

11%

2%

Cyber criminali

Hacktivist (es.

Anonymous)

Spionaggio

Guerra Informatica

• Danni fisici

o Persone ferite

o Danni ad oggetti

• Danni d’immagine

o Perdita di clienti o di vendite

o Riduzione dei profitti

• Conseguenze legali di una breccia nel sistema informatico

Gestione del rischio – Risposta ed Identificazione del rischio

Il rischio può essere gestito in 5 modi:

• Avoiding (Evitare) – Non è possibile trovare un’opzione valida che riduca l’impatto e la probabilità

del rischio ad un livello accettabile, bisogna quindi cambiare la strategia o i piani per evitare proprio

completamente il rischio.

• Mitigating (Mitigare) – Prendere dei provvedimenti per ridurre la probabilità o l’impatto che un ri-

schio ha o potrebbe avere.

• Sharing/Transferring (Condividere/Trasferire) – La probabilità e l’impatto di un rischio sono ridotti,

trasferendo o condividendo una parte del rischio.

• Monitoring – Controllare periodicamente la probabilità o l’impatto di un rischio.
• Accepting (Accettare) – Decidere di prendersi il rischio e preparare dei piani per tuttelarsi nel caso in

cui il rischio si verifichi.

Sostanzialmente queste diverse metodologie di risposta vengono applicate in base alla verosimiglianza che

questo rischio si verifichi. Quindi se un rischio è:

• Basso – Se il rischio ricade sotto la soglia di propensione al rischio dell’azienda allora non è richiesto

alcun tipo di mitigazione del rischio.

➔ Si opta quindi per l’ACCEPTING

• Medio – Il rischio è al di sopra della soglia di accettazione ma rimane pur sempre sotto la soglia di

tolleranza del rischio. Questi rischi sono costantemente monitorati e gestiti dalle organizzazioni.

➔ Si opta quindi per il MONITORING

• Alto - Il rischio eccede entrambe le soglie sia quella di propensione, sia quella di tolleranza. Questo

tipo di rischio richiede un alto livello di attenzione dai dirigenti che devono scegliere quale strategia

applicare.

➔ Si opta quindi per il MITIGATING oppure per lo SHARING/TRANSFERRING oppure per l’AVOIDING.

Approccio alla mitigazione del Cyber-rischio

L’obbiettivo di questo corso è concentrarsi su come mitigare il rischio, ovvero ridurre le vulnerabilità di un

software ed in parte ridurre l’impatto che un incidente informatico può avere, in quanto non possiamo ri-

durre le minacce che sono fattori esterni.

Ci siamo chiesti allora cosa volesse dire mitigare il rischio ed abbiamo allora introdotto dei concetti chiave.

Per ridurre il rischio si può operare in due via:

• a livello di sistema: firewall, antivirus…
• a livello di software: dobbiamo progettare dei software che siano il più possibili sicuri.

La sicurezza del software non è la stessa cosa di software di sicurezza. Un software di sicurezza (in sintesi si

occupa di sicurezza) ha come suo requisito la capacità di mettere in sicurezza un sistema (firewall, …), mentre

la sicurezza del software sta nella sua capacità di essere il meno vulnerabile possibile a prescindere da di che

cosa si occupi.

L’ultimo concetto chiave sta nel fatto che nel ragionare sulla sicurezza di un software non bisogna trascurare

il fattore umano (es. metropolitana di Londra), in quanto va considerato che le persone possono agire (anche

inconsapevolmente) in modo da creare delle vulnerabilità.

Bisogna quindi istruire gli utilizzatori finali sul perché devono compiere certe azioni, perché il software utilizza

tali protocolli per interagire.

Chi si occupa di Cybersecurity deve imparare a ragionare come le “persone normali” che andranno poi ad

utilizzare quel software. Come diceva Luca Viganò, non dobbiamo essere troppo sicuri di cosa faranno le

persone malintenzionate; dobbiamo cercare di capire cosa però andranno a fare i normali utilizzatori, che

potrebbero mettere a repentaglio, senza volere, la sicurezza di un sistema. Dobbiamo quindi cercare di anti-

cipare tutti i comportamenti ed evitare che questi possano causare danni.

Quindi vanno prese in considerazione due cose:

1. innanzi tutto, le persone che andranno ad utilizzare il software che stiamo progettando devono es-

sere “addestrate” in modo adeguato, perché devono imparare che cos’è la sicurezza informatica in

modo da comprendere il perché di certe azioni che il software richiede, il perché un software ha

determinati protocolli e l’interazione con gli utenti. Questo significa che prima di far utilizzare un

determinato software bisognerebbe far fare all’utente dei corsi di addestramento nei quali si spiega

non solo come utilizzare il programma, ma anche quali sono le conseguenze nel caso di un utilizzo

errato;

2. chi si occupa di cyber security deve imparare a ragionare come le “persone normali”, ovvero quelle

che andranno ad utilizzare quel software, ovvero bisogna anticipare tutti i possibili comportamenti e

dove possibile fare in modo che i comportamenti errati non siano resi possibili.

Sommerville, inoltre disse che la sicurezza del software, dipende però anche da quella del sistema, in quanto

per quanto possa essere sicuro il software, questo si troverà a girare sul sistema e se il sistema non è sicuro

anche il software a quel punto non è al sicuro.

Somerville riprende quindi il concetto di sistema socio-tecnico all’interno del quale il nostro software si tro-

verà ad agire, anche perché questo è l’unico modo per capire dove si possano aprire brecce nella sicurezza

del sistema. Con sistema socio-tecnico si vuole intendere che un software, girerà su una determinata mac-

china, inserita in un determinato ambiente, in questo ambiente possono esserci altri dispositivi sui quali gi-

reranno altri software, questi altri dispositivi potrebbero interagire con il “nostro”, ci saranno anche delle

persone che utilizzeranno quei dispositivi ed il nostro software, in sintesi dobbiamo considerare l’ambiente

appunto socio-tecnico composto sia da persone che da dispositivi software e hardware all’interno del quale

il nostro software si troverà ad agire. Solo tenendo in considerazione tutti questi aspetti possiamo prevedere,

del trattamento mette in atto misure tecniche e organizzative adeguate, quali

la pseudonimizzazione, volte ad attuare in modo efficace i principi di prote-

zione dei dati, quali la minimizzazione, e a integrare nel trattamento le neces-

sarie garanzie al fine di soddisfare i requisiti del presente regolamento e tute-

lare i diritti degli interessati.

2. Il titolare del trattamento mette in atto misure tecniche e organizzative ade-

guate per garantire che siano trattati, per impostazione predefinita, solo i dati

personali necessari per ogni specifica finalità del trattamento. Tale obbligo

vale per la quantità dei dati personali raccolti, la portata del trattamento, il pe-

riodo di conservazione e l'accessibilità. In particolare, dette misure garanti-

scono che, per impostazione predefinita, non siano resi accessibili dati perso-

nali a un numero indefinito di persone fisiche senza l'intervento della persona

fisica.

[…]

L’art.32 riguarda invece la sicurezza dell’elaborazione, ovvero i dati raccolti quando vengono elaborati, de-

vono essere elaborati in sicurezza. Nell’articolo sono anche dati alcuni consigli, quali quello di utilizzare pseu-

donimi quando possibile, il criptare i dati personali ,…

Articolo 32

Sicurezza del trattamento

1. Tenendo conto dello stato dell'arte e dei costi di attuazione, nonché della

natura, dell'oggetto, del contesto e delle finalità del trattamento, come anche

del rischio di varia probabilità e gravità per i diritti e le libertà delle persone fi-

siche, il titolare del trattamento e il responsabile del trattamento mettono in

atto misure tecniche e organizzative adeguate per garantire un livello di sicu-

rezza adeguato al rischio, che comprendono, tra le altre, se del caso:

a) la pseudonimizzazione e la cifratura dei dati personali;

b) la capacità di assicurare su base permanente la riservatezza, l'integrità, la di-

sponibilità e la resilienza dei sistemi e dei servizi di trattamento;

c) la capacità di ripristinare tempestivamente la disponibilità e l'accesso dei

dati personali in caso di incidente fisico o tecnico;

d) una procedura per testare, verificare e valutare regolarmente l'efficacia

delle misure tecniche e organizzative al fine di garantire la sicurezza del tratta-

mento.

[…]

Modelli formali

Blueprint for a science of cybersecurity

Nel 2012 Fred B. Schneider, un ricercatore abbastanza famoso nel campo della cyber security, scrisse un

articolo dal titolo “Blueprint for a science of cybersecurity”, dove di fatto enuncia che la cyber security non

può essere trattata solo da un punto di vista qualitativo, ma si rende necessario ad un certo punto adottare

dei modelli formali, in modo da avere delle risposte più precise e rigorose in termini di sicurezza informatica.

Il principio su cui si basò Schneider era il seguente: “L’ingegneria di fatto viene anche chiamata scienza appli-

cata, in quanto utilizza dei modelli matematici (modelli formali) e li applica alla progettazione oppure all’ana-

lisi di un sistema artificiale costruito dall’uomo”.

Una breve introduzione alla probabilità

Un esperimento nel campo delle probabilità è un’azione attraverso la quale si possono ottenere specifici

risultati (un numero, una misura o una risposta).

Es. lancio di un dado

L’ esito altro non è che il risultato di un esperimento.

Es. faccia che esce dal lancio del dado

L’insieme di tutti i possibili esiti è lo spazio campione

Es. tutte le possibili facce che possono uscire {1,2,3,4,5,6}

Un evento consiste in uno o più esiti che fanno parte di un sottoinsieme dello stesso spazio campione

Es. Dal lancio esca una faccia pari.

Un evento semplice è un evento costituito da un solo esito

Es. dal lancio del dado esca la faccia 6

Noi ci troviamo ora a ragionare in questi termini: abbiamo uno spazio con tutti i possibili esiti, poi si vuole

ragionare su alcuni possibili esiti (quindi su un qualche sottoinsieme dello spazio di tutti i possibili eventi) e

vogliamo quindi sapere quante possibilità si hanno che si verifichi quel dato evento.

Si sta quindi in un certo qual modo parlando di misura, si sta misurando la “dimensione” dell’evento rispetto

alla “dimensione” dello spazio.

Riformulando quanto appena detto noi siamo interessati a conoscere la probabilità che si verifichi un evento

dato un determinato spazio di campioni.

Per calcolare le probabilità abbiamo diversi approcci:

• Approccio assiomatico → vengono formulati determinati assiomi sulla base dei quali si vanno a di-

mostrare i vari teoremi. La base assiomatica del calcolo delle probabilità è composta da 3 assiomi.

I 3 assiomi sono:

1. Per un evento A, la probabilità che A si verifichi e più grande o uguale a 0. ∀𝐴 𝑃(𝐴) ≥ 0
2. La probabilità che almeno uno degli eventi dello spazio campione si verifichino è 1. 𝑃(𝑆) = 1
3. Se l’evento A e l’evento B sono mutuamente esclusivi si può dire che 𝑃(𝐴 ∪ 𝐵) = 𝑃(𝐴) + 𝑃(𝐵)

La probabilità condizionale

È la probabilità che avvenga un determinato evento a condizione che prima se ne sia verificato un altro. La

notazione è la seguente: Pr

che si legge come “probabilità di B dato A”.

Esempio: Abbiamo 5 fish rosse, 4 fish blu e 6 fish bianche in un cesto. Se vengono casualmente pe-

scate 2 fish. Qual è la probabilità che la seconda fish estratta sia rossa dato che la prima estratta era

blu? (Assumendo che la prima fish estratta non viene rimessa nel cesto).

Risoluzione: Visto che la prima fish è stata estratta e non reimmessa, ci sono solo 14 fish rimanenti,

di cui 5 rosse.

Risultato: Pr

𝑓𝑖𝑠ℎ_𝑟𝑜𝑠𝑠𝑎

𝑓𝑖𝑠ℎ_𝑏𝑙𝑢

5

14

Per la probabilità condizionale risultano alquanto importanti il teorema di Bayes. Ora per gradi arriveremo

appunto a questo teorema.

Immaginiamoci una situazione (quella rappresentata nella figura sotto), dove 𝑆 è lo spazio di tutti i possibili

esiti e supponiamo di partizionarlo in un certo numero di partizioni (𝐴 1

10

). Ognuna di queste partizioni,

in base alla terminologia precedentemente introdotta può essere vista come un evento (n.b. ogni evento è

un sottoinsieme dello spazio di tutti gli esiti possibili). Prendiamo ora un altro evento, l’evento 𝐵, questo si

intersecherà con le varie partizioni (non per forza con tutte quante come nel disegno)

Partizione significa che ogni insieme della partizione è disgiunto dagli altri e tutti insieme danno la totalità.

Esistono alcuni teoremi che ci portano alla formulazione del teorema di Bayes:

• Teorema della probabilità composta:

Pr(𝐴

𝑗

∩ 𝐵) = Pr(𝐵|𝐴

𝑗

) Pr(𝐴

𝑗

) = Pr (𝐴

𝑗

|𝐵)Pr (𝐵)

Indica che la probabilità che l’evento 𝐴

𝑗

, uno qualsiasi di questa partizione, intersecato 𝐵, ovvero ci

si chiede qual’è la probabilità che si verifichino contemporaneamente l’evento 𝐴

𝑗

e l’evento 𝐵, ov-

viamente questo tra tutti gli esiti possibili.

Il teorema della probabilità composta ci dice che questa probabilità è pari alla probabilità che si ve-

rifichi 𝐵 condizionato dal verificarsi di 𝐴

𝑗

, moltiplicata per la probabilità che si verifichi 𝐴

𝑗

→ questo

perché si parte dal presupposto che l’evento 𝐴

𝑗

si sia verificato e dato ciò va a vedere la probabilità

che si verifichi pure 𝐵. Ovviamente vale anche il ragionamento opposto.

• Legge della probabilità totale:

Pr

= ∑ Pr(𝐵|𝐴

𝑗

) Pr (𝐴

𝑗

𝑗

Dal precedente teorema è facile derivare questo secondo teorema che va sotto il nome di “Legge

della probabilità totale”. Ripartendo dalla situazione esposta prima ci dice come calcolare la sola

probabilità di 𝐵. In pratica si va ad unire la probabilità che si verifichi 𝐵 dato il verificarsi di ogni

evento della partizione.

• Teorema di Bayes:

𝐴

𝐴

𝐴

𝐴

𝐴

𝐴

𝐴

𝐴

𝐴

𝐴

𝐵

𝑆

Pr(𝐴

𝑖

Pr

𝑖

Pr (𝐴

𝑖

Pr(𝐵|𝐴

𝑗

) Pr (𝐴

𝑗

𝑗

Dati i due teoremi precedenti si può facilmente giungere alla formulazione del teorema di Bayes.

Questo teorema mi dice che la probabilità del verificarsi dell’evento 𝐴

𝑖

condizionata da 𝐵 è uguale

alla probabilità di avere 𝐵 condizionata ad 𝐴

𝑖

, per la probabilità di 𝐴

𝑖

, fratto la sommatoria per ogni

𝑗 della probabilità di 𝐵 dato 𝐴

𝑗

per la probabilità di 𝐴

𝑗

Il teorema di Bayes risulta di notevole importanza perché ha aperto dal punto di vista dell’inferenza

statistica.

Approccio frequentista ed approccio baynesiano

Prendiamo ora in considerazione un esempio fatto da Floyd Bullard. (Siamo nel campo dell’inferenza stati-

stica non più in quello delle probabilità).

Consideriamo un’urna (opaca, così non ne vediamo il contenuto), che contiene un numero finito ma molto

grande di perline.

È noto che tutte le perline sono o rosse o bianche. Ma non si ha la benchè minima idea della ripartizione delle

perline tra i due colori.

Si cominciano ad estrarre perline, senza reinserirle. Dopo diverse estrazioni ci si rende conto che tutte le

perline fino ad ora estratte sono rosse.

Vedendo che continuando ad estrarre perline, queste sono ancora rosse, che inferenza si può fare riguardo

al fatto che la prossima perlina estratta sia rossa?

Posso dire che la probabilità che la prossima estrazione mi restituisca una pallina rossa sia:

• Decrescente → in quanto si stanno togliendo perline rosse dall’insieme finito di quest’ultime;
• Crescente → in quanto si stanno continuando ad estrarre solo perline rosse, si tende a credere che

non ci siano perline bianche nell’urna, e quindi questa contenga solo perline rosse

Nel caso si creda che la probabilità sia decrescente, si segue il pensiero frequentista (con un approccio clas-

sico all’inferenza statistica), mentre se si crede che la probabilità sia crescente, si segue il pensiero Bayne-

siano.

La differenza tra statistica e calcolo delle probabilità (che sono uno il duale dell’altro) sta nel fatto che: nel

calcolo delle probabilità noi conosciamo l’universo e ci chiediamo andando ad estrarre un campione da que-

sto universo che cosa succede (quindi conosco l’universo, il campione ovvero l’esperimento, e vorrei preve-

dere l’esito). Nella statistica, si ragiona esattamente all’opposto, ovvero parto dal campione e cerco di capire

come è fatto l’universo. Con la statistica mi interessa sapere qual è la distribuzione della probabilità sull’intero

universo (che non conosco), conoscendo la distribuzione della probabilità sul campione.

Probabilità a priori e a posteriori

Il ragionamento baynesiano si basa sul concetto di probabilità a priori e a posteriori.

Il teorema di Bayes può essere ripreso e riletto in termini di probabilità a posteriori e a priori:

Usiamo il simbolo di proporzionale ∝ in quanto abbiamo rimosso il denominatore dalla formula per concen-

trarci solamente sul numeratore. Andiamo ora ad analizzare la formula:

Pr

𝑖

Pr(𝐵|𝐴

𝑖

)Pr (𝐴

𝑖

)

∑ Prቀ𝐵|𝐴

𝑗

ቁPr (𝐴

𝑗

)

𝑗

Pr(𝐴

𝑗

|𝐵) ∝ Pr(𝐵|𝐴

𝑗

) ∗ Pr (𝐴

𝑗

𝑝𝑜𝑠𝑡𝑒𝑟𝑖𝑜𝑟 ∝ 𝑙𝑖𝑘𝑒𝑙𝑖ℎ𝑜𝑜𝑑 ∗ 𝑝𝑟𝑖𝑜𝑟

Un esempio concreto

Volendo concretizzare quanto finora detto riguardo al calcolo delle probabilità nel campo della cyber security

ci apprestiamo a vedere l’esempio delle “code smell” (“puzze del codice”→pratiche non corrette nella scrit-

tura del codice, che non inficiano il funzionamento del programma ma aumentano le probabilità di errore nel

codice e potrebbero rendere il software creato più vulnerabile ad attacchi). Alcune code smell sono:

• Mysterious Name: funzioni, moduli, variabili o classi che sono nominati in una maniera che non co-

munica cosa effettivamente fanno o come verranno utilizzate;

• Duplicated code: codice identico o molto simile che esiste in più punti;
• Large class: una classe che cresce fino a diventare troppo grande;
• Too many parameters: una lista troppo lunga di parametri, che rende difficoltosa la lettura, e rende

le chiamate e il testing della funzione complicata;

• Long method: un metodo, una procedura o una funzione che è troppo grande.

Alla luce di quanto scritto nel paragrafo precedente analizziamo il seguente esempio.

Supponiamo di avere uno strumento automatico che preso in ingresso il codice del programma che vogliamo

controllare, segnala tutti i code smell presenti.

Supponiamo, che una volta lanciato tale strumento, scopriamo che la probabilità che un code smell sia pre-

sente (TestPos), dovuto alla presenza di una vulnerabilità (Pos), è pari a 0.99.

Supponiamo, inoltre, che il fatto che un code smell non sia presente (TestNeg), dato dall’assenza di una vul-

nerabilità (Neg), è pari a 0.87.

La probabilità che una vulnerabilità sia presente (Pos) in un software scritto in C e pari a 0.10. (Da notare che

questa altro non è che la probabilità a priori).

Qual è la probabilità che un codice scritto in C abbia una vulnerabilità (Pos) data dalla presenza di un code

smell (TestPos)?

Riscrivendo quanto appena detto in formule, per poter poi fare i calcoli utilizzando il teorema di Bayes:

• Supponiamo, che una volta lanciato tale strumento, scopriamo che la probabilità che un code smell

sia presente (TestPos), dovuto alla presenza di una vulnerabilità (Pos), è pari a 0.99.

Pr

Pr(𝑇𝑒𝑠𝑡𝑁𝑒𝑔|𝑃𝑜𝑠) = 0. 01

• Supponiamo, inoltre, che il fatto che un code smell non sia presente (TestNeg), dato dall’assenza di

una vulnerabilità (Neg), è pari a 0.87.

Pr(𝑇𝑒𝑠𝑡𝑁𝑒𝑔

Pr

• La probabilità che una vulnerabilità sia presente (Pos) in un software scritto in C e pari a 0.10.

Pr

La probabilità che un codice scritto in C abbia una vulnerabilità (Pos) data dalla presenza di un code smell

(TestPos), calcolata applicando il teorema di bayes è:

Pr(𝑃𝑜𝑠

( 0 , 10 )( 0 , 99 )

( 0 , 10 )( 0 , 99 )+( 0 , 9 )( 0 , 13 )

0 , 099

0 , 216

Avendo ora le nozioni base andiamo a vedere la modellizzazione di sistemi mediante la rappresentazione

degli stati.

Terminologia

In questo capitolo ci limiteremo a spiegare il significato di alcuni termini, questo al fine di meglio compren-

dersi quando si parla di cyber security.

System Dependability

Il focus principale di questo corso è quello di progettare dei software che siano dependable ovvero garanti-

scano la proprietà che in italiano abbiamo tradotto con “fidatezza”, ovvero che siano dei software fidati, dei

quali ci si può fidare.

Abbiamo inoltre visto che questo concetto generale di “fidatezza” può essere declinato in tanti modi, ovvero

come sicurezza, affidabilità, disponibilità, resilienza, …

In realtà, tutti questi concetti sono tra loro interdipendenti.

Come si ottiene la dependability?

Questa si ottiene in fase di progettazione e realizzazione di un software, tenendo in considerazione tutti i

possibili eventi avversi, che possono quindi compromettere la availability, la reliability, la safety, la security

e la resilience; e progettando quindi il software in maniera tale che sia in grado di riconoscere e resistere ad

eventuali eventi avversi e che in caso questi avvengano sia in grado di riprendere a funzionare regolarmente.

Costi della dependability

Quanto appena detto, banalmente comporta un costo. Un costo che in realtà si divide in:

Dependability

Availability

La capacità del

sistema di

fornire servizi

quando richiesti.

Reliability

La capacità del

sistema di

fornire un

servizio come

specificato.

Safety

La capacità del

sistema di

operare senza

fallimenti

catastrofici.

Security

La capacità del

sistema di

proteggere se

stesso contro

intrusioni sia

volontarie che

accidentali.

Resilience

La capacità del

sistema di

resistere e di

ristabilirsi da

eventi dannosi.