Perché conta

Quasi ogni rete che ho visto è stata messa in sicurezza al contrario: prima si compra il firewall, poi si decide cosa deve bloccare. Il risultato sono regole scritte “a sensazione”, porte aperte che nessuno ricorda perché, e zone della rete che si fidano l’una dell’altra senza motivo.

Il threat modeling ribalta l’ordine. Prima si disegna la rete, poi si chiede cosa può andare storto, e solo alla fine si sceglie la difesa. È il capitolo 01 della serie perché tutti i capitoli successivi rispondono a minacce che troveremo qui.

What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job?

― Threat Modeling Manifesto

Quattro domande. Il resto del post le applica una per una.

Domanda 1: su cosa stiamo lavorando?

L’esempio è un piccolo ufficio, il tipo di rete che si trova in uno studio professionale o in una startup:

• 15 postazioni e una stampante di rete;
• un NAS con i documenti condivisi;
• una rete Wi-Fi per gli ospiti;
• un server web pubblico in DMZ;
• accesso remoto in VPN per chi lavora da casa.

Il diagramma

Il diagramma serve a una cosa sola: rendere visibili i confini di fiducia (trust boundary), cioè i punti in cui i dati passano da una zona con un livello di fiducia a un’altra. Le minacce si concentrano quasi sempre lì.

  flowchart LR
    Internet((Internet))
    subgraph DMZ["DMZ · fiducia bassa"]
        Web[Server web]
    end
    subgraph LAN["LAN uffici · fiducia media"]
        PC[Postazioni]
        PR[Stampante]
        NAS[(NAS)]
    end
    subgraph GUEST["Wi-Fi ospiti · nessuna fiducia"]
        G[Dispositivi ospiti]
    end
    Remote[Utenti VPN]
    FW{{Firewall}}
    Internet <--> FW
    Remote -. tunnel VPN .-> FW
    FW <--> Web
    FW <--> PC
    PC <--> NAS
    PC --> PR
    FW <--> G
    classDef tb stroke:#e63946,stroke-width:2px,stroke-dasharray:6 4;
    class DMZ,LAN,GUEST tb;

Ogni riquadro tratteggiato è una zona; ogni freccia che attraversa il firewall attraversa un confine di fiducia. In questa rete ce ne sono quattro: Internet–firewall, firewall–DMZ, firewall–LAN e firewall–ospiti. Il tunnel VPN ne aggiunge un quinto.

L’inventario

Il diagramma deve corrispondere alla rete reale, non a quella che si crede di avere. Una scansione della LAN dice cosa c’è davvero:

1
2
3
4
5

# Host attivi nella LAN, senza scansione delle porte
sudo nmap -sn 192.168.10.0/24 -oG - | awk '/Up$/{print $2, $3}'

# Servizi esposti sul NAS: spesso ce ne sono più di quanti ne servano
sudo nmap -sV --top-ports 200 192.168.10.20

Quasi sempre salta fuori qualcosa che non era nel diagramma: una telecamera IP, un vecchio access point, un’interfaccia di gestione della stampante raggiungibile in HTTP.

Domanda 2: cosa può andare storto?

Qui entra STRIDE. È un acronimo che elenca sei categorie di minaccia, ognuna opposta a una proprietà di sicurezza. Serve a non dimenticare nulla: per ogni elemento del diagramma si passano in rassegna tutte e sei.

STRIDE applicato ai confini

Applicato ai confini del nostro ufficio, STRIDE produce un elenco come questo (ridotto alle voci più interessanti):

Ogni riga dice dove (il confine), cosa (la categoria STRIDE) e come (lo scenario concreto). Una minaccia scritta in modo vago, come “il NAS potrebbe essere attaccato”, non aiuta a scegliere una difesa.

Domanda 3: cosa facciamo?

Non si può risolvere tutto subito. Per decidere l’ordine serve una stima del rischio. La formula più semplice è anche la più usata:

$$ R = P \times I $$

dove $P$ è la probabilità che la minaccia si realizzi e $I$ è l’impatto se succede, entrambi su una scala da 1 a 5. Il risultato va da 1 a 25. Non è una misura precisa: serve solo a confrontare le minacce tra loro con lo stesso metro.

Ordinando per $R$, la priorità diventa evidente: la prima cosa da fare non è comprare un IDS, ma separare la rete ospiti. Costa poco e chiude la minaccia con il rischio più alto.

Il registro delle minacce

Conviene tenere le minacce in un file versionato accanto alla configurazione della rete. Un formato semplice basta:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

- id: T1
  boundary: guest -> lan
  stride: [E]
  threat: Un ospite raggiunge il NAS sulla stessa VLAN
  likelihood: 4
  impact: 5
  risk: 20
  mitigation: VLAN 30 per gli ospiti, ACL deny verso 192.168.10.0/24
  status: open
  owner: rete

Le righe evidenziate sono quelle che decidono la priorità. Il campo status permette di vedere a colpo d’occhio cosa resta aperto.

Domanda 4: abbiamo fatto un buon lavoro?

Un threat model non è mai finito. Va ripreso ogni volta che la rete cambia: un nuovo servizio in DMZ, un nuovo tipo di dispositivo, un fornitore che chiede l’accesso remoto. Tre controlli pratici:

1. Il diagramma corrisponde alla rete? Ripetere la scansione dell’inventario e confrontare.
2. Ogni minaccia ha una difesa e un responsabile? Le righe senza owner non vengono chiuse.
3. Le difese funzionano? Provarle davvero. Ad esempio, da un dispositivo nella Wi-Fi ospiti:

1
2

# Deve fallire: gli ospiti non devono raggiungere il NAS
nc -zv -w 3 192.168.10.20 445 && echo "T1 ANCORA APERTA" || echo "T1 chiusa"

Lab

Prendete la rete di casa vostra (o del laboratorio descritto nella roadmap) e rispondete alle quattro domande:

1. Disegnate il diagramma con le zone e i confini di fiducia.
2. Applicate STRIDE ad almeno tre confini.
3. Calcolate $R$ per ogni minaccia e ordinatele.
4. Scegliete la prima difesa da applicare e verificate che funzioni.

Conclusione

Il threat modeling non richiede strumenti costosi: un diagramma, una tabella e quattro domande. Il valore sta nell’ordine che impone: prima capire la rete, poi scegliere le difese in base al rischio, non all’abitudine.

Le minacce trovate qui sono la scaletta dei prossimi capitoli. Si parte dalla T2, perché è la più sottovalutata: un attaccante già dentro la LAN che si mette in mezzo al traffico.

Prossimo nella serie: 02 · Attacchi a livello 2: ARP spoofing, MAC flooding e DHCP starvation · Torna alla roadmap