Commento alla domanda 2 della sessione pomeridiana dell'esame Registered Information Security Specialist, autunno 2023 (Reiwa 5) — File che escono dal Wi-Fi ospiti

Hanno vietato il collegamento delle chiavette USB. Hanno vietato anche il salvataggio di file sul disco locale. Hanno tagliato le comunicazioni verso webmail e archiviazione cloud non autorizzate dall’azienda. Hanno vietato anche l’allegato di file alle e-mail. Hanno abolito il file server interno.

Eppure i file aziendali si possono portare via.

La domanda 2 della sessione pomeridiana dell’esame Registered Information Security Specialist, autunno 2023 (Reiwa 5), ha come palcoscenico la società di abbigliamento M, che ha già messo in atto tutte queste contromisure, e chiede di elencare i buchi che restano¹. Questo articolo è il secondo di una serie che segue il commento alla domanda 1 (XSS memorizzato), e l’ambito trattato si sposta dall’applicazione Web alla rete interna e all’autenticazione dei dispositivi.

Se la domanda 1 chiedeva «dove le contromisure allineate davanti all’app Web sono state aggirate», la domanda 2 chiede «quale ambito il progetto delle contromisure intendeva proteggere». Nessuna delle contromisure della società M è sbagliata. Solo, se si conferma uno per uno il perimetro che ciascuna intendeva coprire, subito fuori è vuoto.

Ciò che si ottiene da questo articolo, oltre alle risposte modello di ciascuna domanda e al loro fondamento, è un insieme di punti di conferma — usabili così com’è in pratica — su tre ambiti: LAN wireless, certificati server e restrizione per indirizzo IP di origine. È scritto in modo che chi lo legge per l’esame possa partire dalle sezioni per domanda, e chi ha bisogno solo del punto di vista pratico possa leggere dal capitolo 11 e dal 12 e il senso resti.

1. Prima di tutto, la conclusione

• Il buco era la sala riunioni. La società M aveva vietato di portare PC di proprietà personale, ma il divieto copriva solo l’area ufficio; la sala riunioni era esclusa. In sala riunioni arrivano sia la LAN wireless dei dipendenti sia quella degli ospiti
• I percorsi di fuoriuscita da parte di un dipendente sono due. Spoofing dell’indirizzo MAC e collegamento alla LAN wireless dei dipendenti, e semplicemente collegarsi alla LAN wireless ospiti. Il secondo è di gran lunga più facile: serve solo la pre-shared key che si dà agli ospiti
• L’archiviazione cloud (servizio B) era ristretta a «accesso possibile solo dall’indirizzo IP globale della società M». Ma anche il traffico della LAN wireless ospiti viene convertito dallo stesso NAT nello stesso indirizzo IP globale, quindi questa restrizione passa dritta. Una restrizione per indirizzo IP di origine è un’impostazione che consente, non un dispositivo, ma tutti coloro che condividono un’uscita
• Un AP falso + un sito falso da parte di un attaccante esterno si ferma con la verifica del certificato server. Ciò che funziona sono due punti: «è stato emesso da un’autorità di certificazione attendibile?» e «il nome server del certificato coincide con quello di destinazione?». Secondo il commento di valutazione dell’IPA, il tasso di risposte corrette della domanda che chiedeva questi due punti era basso
• Anche se si sbaglia e si scrive http://, HSTS sostituisce con HTTPS e poi si collega, quindi di nuovo si arriva a un errore di certificato. Inoltre, su un host su cui HSTS è attivo, non si deve offrire all’utente la scelta di ignorare l’avviso e andare avanti
• Anche la funzione di condivisione file legittima diventa un percorso di fuoriuscita. Basta specificare il proprio indirizzo privato come indirizzo e-mail del condivisore esterno. L’approvazione del superiore c’era, ma c’erano superiori che non confermavano il destinatario
• I pilastri della contromisura sono tre. Mettere la LAN wireless dei dipendenti su EAP-TLS e autenticare con un certificato client per dispositivo, e mettere la chiave privata nel TPM in modo che non si possa estrarre dal PC aziendale. Staccare la LAN wireless ospiti dalla rete della società M (o separare l’indirizzo IP globale di uscita). E cancellare VLAN, regole di filtro e SSID che non si usano più

Mappa della conoscenza di questo articolo

Questo articolo è un commento di revisione di progetto intorno a LAN wireless e certificati server, con palcoscenico la domanda 2 della sessione pomeridiana dell’esame Registered Information Security Specialist, autunno 2023 (Reiwa 5). WPA2-PSK, in cui tutti condividono la stessa chiave, ha la debolezza che chiunque conosca la chiave può alzare un AP falso (evil twin) indistinguibile dal vero; ma se ci sono la verifica del certificato server e HSTS, l’accesso a un sito falso non si regge. Nella fuoriuscita da parte di un dipendente, allo spoofing dell’indirizzo MAC risponde EAP-TLS con certificato client e RADIUS, e al problema della restrizione per indirizzo IP di origine aggirata dall’uscita NAT condivisa da più reti risponde l’isolamento della rete ospiti. Memorizzare la chiave privata nel TPM in modo che non si estragga è la chiave che fa funzionare davvero l’autenticazione con certificato.

flowchart LR
    accTitle: Mappa della conoscenza della domanda 2 della sessione pomeridiana dell'esame Registered Information Security Specialist, autunno 2023 (Reiwa 5) (LAN wireless e certificato server)
    accDescr: Diagramma che mostra come la debolezza di WPA2-PSK dovuta alla chiave condivisa porti allo spoofing dell'indirizzo MAC e all'attacco evil twin, mentre la verifica del certificato server e HSTS impediscono l'accesso a un sito falso; come EAP-TLS con RADIUS e la chiave privata nel TPM realizzino l'autenticazione per dispositivo; e i limiti della restrizione per IP di origine condivisa tramite NAT e la sua correzione.
    wpa2_psk["WPA2-PSK"]
    eap_tls["EAP-TLS"]
    evil_twin["Attacco evil twin (gemello diavolo)"]
    phishing["Phishing"]
    mac_address_filtering["Filtro degli indirizzi MAC"]
    mac_address_spoofing["Spoofing dell'indirizzo MAC"]
    server_certificate_validation["Verifica del certificato server"]
    certificate_chain["Catena di certificati"]
    root_ca["Certificato CA radice"]
    certificate_revocation_check["Conferma di revoca del certificato"]
    trust_anchor_risk["Rischio di abuso del punto di partenza della fiducia"]
    hsts["HSTS (HTTP Strict Transport Security)"]
    hsts_preload_list["Elenco di preload HSTS"]
    client_certificate["Certificato client"]
    radius["RADIUS"]
    ieee_802_1x["IEEE 802.1X (EAP over LAN)"]
    network_policy_server["Network Policy Server (NPS)"]
    private_key["Chiave privata"]
    tpm["TPM"]
    key_exfiltration_risk["Rischio di fuoriuscita della chiave privata"]
    shared_egress_ip_bypass["Aggiramento della restrizione IP di origine tramite IP di uscita condiviso"]
    nat["NAT (network address translation)"]
    guest_network_isolation["Isolamento della rete ospiti"]
    unused_config_cleanup["Eliminazione delle impostazioni non più usate"]
    source_ip_restriction["Restrizione per indirizzo IP di origine"]
    wpa2_psk -->|"può causare"| evil_twin
    evil_twin -.->|"può causare"| phishing
    mac_address_filtering -->|"sconsigliato per"| mac_address_spoofing
    eap_tls -->|"consigliato per"| mac_address_spoofing
    server_certificate_validation -.->|"previene"| phishing
    server_certificate_validation -->|"usa"| certificate_chain
    server_certificate_validation -->|"usa"| root_ca
    server_certificate_validation -.->|"usa"| certificate_revocation_check
    root_ca -.->|"può causare"| trust_anchor_risk
    hsts -.->|"previene"| phishing
    hsts -->|"richiede"| server_certificate_validation
    hsts_preload_list -.->|"mitiga"| evil_twin
    eap_tls -->|"usa"| client_certificate
    eap_tls -.->|"usa"| radius
    eap_tls -.->|"usa"| ieee_802_1x
    network_policy_server -->|"implementa"| radius
    client_certificate -->|"richiede"| private_key
    private_key -.->|"salvato in"| tpm
    tpm -.->|"previene"| key_exfiltration_risk
    shared_egress_ip_bypass -.->|"richiede"| wpa2_psk
    nat -->|"può causare"| shared_egress_ip_bypass
    guest_network_isolation -->|"previene"| shared_egress_ip_bypass
    guest_network_isolation -->|"deve precedere"| unused_config_cleanup
    source_ip_restriction -.->|"incompatibile con"| nat

Nel diagramma, una linea continua indica una relazione che vale sempre e una linea tratteggiata indica una relazione condizionale (le condizioni sono nella spiegazione di ciascuna relazione nella pagina di dettaglio). L’elenco completo delle relazioni (in totale 24, con evidenza e livello di certezza) e le definizioni dei concetti principali sono raccolti nella pagina di dettaglio della mappa della conoscenza (in giapponese). Dati: JSON-LD / Turtle

2. Sul materiale — Fonte e come lo si tratta in questo articolo

La domanda trattata è la seguente.

Fonte: esame Registered Information Security Specialist, autunno 2023 (Reiwa 5), sessione pomeridiana, domanda 2

L’IPA, per le domande d’esame del passato che pubblica, afferma che salvo disposizioni speciali di legge non servono autorizzazione né diritti d’uso. Non ha però rinunciato al diritto d’autore, e chiede di indicare la fonte nella forma «anno, sessione, tipo di esame, fascia oraria, numero di domanda ecc.» e, se si è modificata una parte della domanda, di indicarlo².

In questo articolo non riproduciamo così com’è le figure e le tabelle del fascicolo della domanda. Le sostituiamo, nell’ambito necessario alla spiegazione del meccanismo, con figure semplificate e sintesi scritte da noi. Anche il testo delle domande e le risposte modello li trattiamo in sintesi. Il testo originale del fascicolo, delle risposte modello e del commento di valutazione si può scaricare gratuitamente dalla pagina dell’IPA: consigliamo di leggerlo tenendolo aperto^{1 3 4}.

Corrispondenza tra domande e questo articolo

Si può iniziare a leggere dalla domanda che si vuole risolvere.

Descrizioni del fascicolo della domanda e come le si tratta in questo articolo

Per poterle confrontare con l’originale, riassumiamo dove e come le abbiamo trattate.

3. Il palcoscenico della domanda — Ciò che la società M «aveva già fatto»

La società M è una società controllata della società L, 100 dipendenti, nel settore dell’abbigliamento. L’edificio degli uffici affaccia su un grande viale di Tokyo con molto passaggio. Questa frase, più avanti, funziona.

L’anno precedente, un dipendente della società M aveva salvato su una chiavetta USB un file di disegno di un prodotto, informazione riservata, conservato sul file server interno, e l’aveva portato a un concorrente. Con la guida della società madre L, è in corso una revisione delle contromisure di sicurezza. Le tre revisioni già attuate sono le seguenti.

• Sui notebook prestati ai dipendenti (di seguito, PC aziendali) è stato introdotto un software di prevenzione della fuoriuscita di informazioni, e sono state impostate: divieto di collegamento di supporti di memoria esterni come chiavette USB; divieto di salvataggio di file sul disco locale salvo l’installazione di software; taglio delle comunicazioni verso webmail e archiviazione cloud non autorizzate dall’azienda; divieto di installazione di software non autorizzato dall’azienda; divieto di allegare file all’invio di e-mail
• Il posto di salvataggio dei file aziendali è stato unificato in un solo punto, l’archiviazione cloud già in uso (di seguito, servizio B), e le impostazioni sono state riviste
• Il file server interno è stato abolito

L’incidente precedente era il percorso «file server interno» → «chiavetta USB», quindi hanno chiuso entrambi gli estremi di quel percorso. La linea è coerente.

Configurazione della rete

Nell’edificio degli uffici ci sono un’area ufficio e una sala riunioni. Nell’area ufficio si usa la LAN wireless dei dipendenti; in sala riunioni si usano sia quella dei dipendenti sia quella degli ospiti. Il proiettore della sala riunioni si usa collegando alla LAN wireless ospiti un terminale portato dall’ospite (PC, tablet, smartphone che l’ospite porta) o un PC aziendale.

Restringendo all’ambito necessario alla spiegazione, la forma è la seguente.

flowchart LR
    accTitle: Configurazione della rete della società M
    accDescr: La LAN wireless ospiti, la LAN wireless dipendenti e la rete server escono verso il servizio B convertite dallo stesso FW NAT in un unico indirizzo IP globale
    subgraph M["Rete interna della società M"]
        direction TB
        G["LAN wireless ospiti<br/>192.168.10.0/24<br/>(solo AP della sala riunioni)"]
        E["LAN wireless dipendenti<br/>192.168.20.0/24<br/>(area ufficio e sala riunioni)"]
        S["Rete server<br/>192.168.30.0/24<br/>DHCP, DNS, directory"]
        FW["FW<br/>NAT converte la sorgente<br/>in un unico indirizzo IP<br/>globale"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["Servizio B<br/>(archiviazione cloud)"]
    FW --> I["Internet"]

Figura 1: Le tre reti ospiti, dipendenti e server escono in Internet convertite dallo stesso FW NAT in un unico indirizzo IP globale.

Le specifiche da fissare sono le seguenti.

E tre regole di sicurezza. Divieto di portare i PC aziendali fuori dall’azienda, divieto di portare nell’area ufficio PC, tablet, smartphone di proprietà personale, divieto di portare file aziendali fuori dall’azienda con metodi diversi dalla funzione di condivisione file del servizio B.

Nella seconda regola avete notato che c’è scritto «nell’area ufficio»? La sala riunioni non è scritta.

Come procede questa domanda

Y del reparto sistemi informativi, con il sostegno del signor S, Registered Information Security Specialist della società madre L, conferma se le contromisure alla fuoriuscita di file dal servizio B sono sufficienti. I due esaminano separando la fuoriuscita da parte di un attaccante esterno e la fuoriuscita da parte di un dipendente. La domanda 1 è la prima, la domanda 2 la seconda, la domanda 3 è l’elaborazione delle contromisure.

4. Wi-Fi falso e sito falso — Domanda 1(1)(2)

La prima cosa che Y elenca è lo scenario in cui un ospite che ha già usato la LAN wireless ospiti, come attaccante, si collega da vicino alla società M alla LAN wireless ospiti e accede al servizio B.

Il motivo per cui questo scenario si regge è che il modo di autenticazione della LAN wireless è WPA2-PSK. PSK (Pre-Shared Key) è, come dice il nome, un modo in cui tutti condividono la stessa chiave. La pre-shared key della LAN wireless ospiti è fatta per essere detta agli ospiti. Una volta detta, non c’è un mezzo per revocare lo stato in cui quella persona la saprà anche in futuro (non resta che cambiarla per tutti). Inoltre l’edificio degli uffici affaccia su un grande viale con molto passaggio, quindi il segnale arriva anche da fuori l’edificio.

La risposta del signor S è chiara. Per accedere al servizio B servono [a] ID utente e [b] password. Questa è la risposta modello della domanda 1(1) (ordine libero). Collegarsi alla LAN wireless, di per sé, non significa accedere al servizio B.

AP falso e sito falso

Y allora fa un passo in più. Che ne dite di un metodo in cui si prepara un AP falso con le stesse impostazioni dell’AP della LAN wireless ospiti e un sito falso con lo stesso URL del servizio B, si manipola l’impostazione DNS e si rubano ID utente e password? Se si mette l’AP falso vicino alla società M, un dipendente della società M potrebbe collegare per errore il PC aziendale all’AP falso, tentare di accedere al servizio B, arrivare al sito falso e fare l’accesso.

È il cosiddetto evil twin (il gemello diavolo). Se si alza un AP con lo stesso SSID e la stessa pre-shared key della LAN wireless ospiti, dal dispositivo non si distingue dall’AP legittimo. Con WPA2-PSK, ciò che il dispositivo può confermare sull’AP è solo «conosce la stessa pre-shared key». Un AP che non conosce la chiave non può completare la procedura di collegamento; detto al contrario, chiunque conosca la chiave può diventare «l’AP vero». Dato che è una chiave che si dà agli ospiti, va pensata come data anche all’attaccante.

Anche qui la risposta del signor S è chiara. Se un dipendente tenta di accedere al sito falso in HTTPS, insieme a un messaggio di errore che non è una connessione sicura, a seconda del certificato server usato sul sito falso, nel browser Web viene visualizzata una o più delle quattro voci seguenti.

• Questo certificato server non è un certificato server emesso da un’autorità di certificazione attendibile (spazio c)
• Il nome server scritto su questo certificato server è diverso dal nome server di destinazione (spazio d)
• Questo certificato server è revocato
• Questo certificato server è scaduto

Le due di sotto sono scritte fin dall’inizio nel fascicolo della domanda; rispondere alle due di sopra (spazi c e d, ciascuno entro 40 caratteri, ordine libero) è la domanda 1(2).

sequenceDiagram
    accTitle: AP falso e sito falso si fermano con la verifica del certificato
    accDescr: Se un dipendente si collega in HTTPS via AP falso, esce un errore perché non è emesso da un'autorità di certificazione attendibile o il nome server non coincide, e la schermata di accesso non viene mostrata
    autonumber
    participant U as PC aziendale del dipendente
    participant F as AP falso e sito falso<br/>(attaccante)
    participant B as Servizio B (legittimo)

    Note over F: Si alza un AP con lo stesso SSID e<br/>la stessa pre-shared key della LAN wireless ospiti
    U->>F: Collegamento per errore all'AP falso
    Note over F: Si manipola il DNS e si punta il<br/>nome di dominio del servizio B al sito falso
    U->>F: Collegamento in HTTPS all'URL del servizio B
    F-->>U: Certificato server del sito falso
    Note over U: La verifica fallisce<br/>· non è emesso da un'autorità di certificazione attendibile<br/>· il nome server del certificato è diverso dalla destinazione
    Note over U: Visualizza un errore che non è una connessione sicura<br/>la schermata di accesso non viene mostrata
    Note over U,B: Con il servizio B legittimo<br/>non si sta nemmeno comunicando

Figura 2: L’accesso HTTPS via AP falso fallisce nella verifica del certificato server; la schermata di accesso non viene mostrata.

Che cosa sta guardando la verifica del certificato

Il commento di valutazione, su questa domanda, scrive così.

La domanda 1(2) ha avuto un tasso di risposte corrette basso. Anche se un attaccante prepara un sito falso, se si accede in HTTPS la verifica del certificato server fallisce. La verifica del certificato server è una conoscenza di base per assicurare la sicurezza della comunicazione, quindi si vorrebbe che si capisse bene, fino a quali voci concrete si verificano.

Anche chi sapeva che «esce un errore di certificato» era poco in grado di scomporre che cosa si conferma e perché si fallisce in quattro voci. Le quattro voci elencate dalla figura 2, organizzate dal punto di vista di a che conferma corrisponde ciascuna, sono le seguenti.

Dal punto di vista dell’attaccante, le due di sopra sono un muro che non si supera. Se si fa un certificato auto-firmato si cade sul primo; anche se si ottiene legittimamente un certificato gratuito per il proprio dominio (per esempio b-service.example.net), la destinazione è il dominio del servizio B, quindi si cade sul secondo. Un certificato per il nome di dominio del servizio B non si ottiene se non si gestisce il dominio del servizio B. Si può dire che la combinazione di questi due punti è il corpo del meccanismo del certificato.

La procedura di verifica del percorso del certificato è definita da RFC 5280⁵; la procedura di confrontare il nome scritto sul certificato e il nome di destinazione è definita da RFC 6125⁶.

Le quattro voci non hanno la stessa forza

Qui separiamo la risposta d’esame e il comportamento reale del browser. Le quattro voci sopra sono ciò che la figura 2 del testo della domanda elenca come «dettaglio dell’errore che può essere visualizzato»; non va letto come se ogni browser le ispezionasse tutte e quattro con la stessa certezza.

Emittente, nome server e scadenza si giudicano, al momento in cui si riceve il certificato, solo con le informazioni a disposizione, quindi vengono sempre verificati. Anche ciò che ferma l’attacco di questa domanda sono questi tre.

La conferma di revoca, invece, ha una natura diversa. Se è revocato o no non è scritto nel certificato: bisogna andare a prendere un’altra informazione, quindi dipende da implementazione e impostazione.

• Chrome di solito non fa conferme OCSP o CRL in linea. Al suo posto distribuisce un elenco limitato chiamato CRLSet, il cui scopo principale è bloccare in fretta un certificato in emergenza, e ciò che viene preso dalle liste di revoca delle CA è solo una parte⁷
• Anche nelle implementazioni che interrogano OCSP, è ampiamente usata una configurazione che, se non si ottiene risposta, fa passare la connessione (soft-fail)

Quindi non fate della «se la chiave privata fuoriesce, basta revocare» il pilastro della contromisura. La revoca è ciò che va fatto, ma non è un meccanismo che funziona con certezza in tutti i browser degli utenti. L’accorciamento del periodo di validità dei certificati degli ultimi anni è anche la risposta del settore al fatto che sulla revoca non si può contare. Se in azienda si sospetta una fuoriuscita di chiave, in parallelo alla richiesta di revoca bisogna arrivare alla sostituzione del certificato e all’invalidazione di ciò che quella chiave proteggeva (sessioni, chiavi API, ecc.).

Trappola in pratica — Chi decide «l’autorità di certificazione attendibile»

Da qui in poi è fuori dal testo della domanda. Il primo della tabella sopra dipende da di che cosa si fida quel dispositivo. L’elenco della fiducia lo hanno browser e sistema operativo; su Windows è «Autorità di certificazione radice attendibili» dell’archivio certificati.

Quindi, nelle situazioni seguenti, il primo controllo passa.

• Si distribuisce ai PC aziendali il certificato radice di una CA interna (CA privata). La chiave privata di quella CA, o la procedura di emissione dei certificati, è in mano all’attaccante
• Un proxy o un prodotto di sicurezza che ispeziona il contenuto della comunicazione mette sul dispositivo un proprio certificato radice per terminare il TLS. Quel prodotto o quella operazione è in mano all’attaccante
• Qualcuno, in passato, ha registrato un’eccezione o ha messo un certificato auto-firmato nella radice attendibile, «perché usciva un errore di certificato»

La terza in campo si vede davvero spesso. Qualcosa messo a mano una volta per far sparire l’errore di certificato di un sistema interno resta nell’immagine ereditata dal PC di un ex dipendente. Il contenuto dell’archivio Autorità di certificazione radice attendibili è, in sé, la dichiarazione di di chi si fida quel dispositivo, quindi fatene oggetto di inventario. Il giudizio su cosa mettere in quale archivio è organizzato nella Guida pratica all’archivio certificati di Windows.

Sul secondo controllo (coincidenza del nome server) c’è un altro punto di attenzione in pratica. Un attacco in cui l’utente sbaglia a vedere il nome di dominio è impotente per il certificato. Se un attaccante ottiene un dominio fuorviante come b-serv1ce.example.com e ottiene un certificato legittimo per quel dominio, il browser non emette un errore. Ciò che il certificato garantisce è «il nome server di destinazione e il nome server del certificato coincidono», non «quel nome server è la controparte che l’utente intendeva». Il meccanismo che non affida quest’ultimo passo all’occhio dell’utente è un modo in cui l’autenticatore verifica l’origine, come le passkey (WebAuthn). Il dettaglio è in Perché le passkey sono sicure.

5. Il motivo per cui si ferma anche se si scrive http:// — Domanda 1(3)

Y non molla. Se, collegati all’AP falso, il dipendente inserisce l’URL del servizio B nel browser Web e per errore scrive http://, il messaggio di errore non viene visualizzato, no?

È un dubbio ragionevole. Se ci si collega in HTTP, il certificato server non compare nemmeno. Il sito falso potrebbe mostrare la schermata di accesso senza alcun errore.

La risposta del signor S è «va bene. HSTS è abilitato, quindi anche in quel caso viene visualizzato lo stesso messaggio di errore di prima». La domanda 1(3) chiede, entro 60 caratteri, il movimento del browser Web fino a subito prima che venga visualizzato questo messaggio di errore.

La risposta modello è «Sostituisce l’accesso HTTP con un accesso HTTPS e accede. Poi riceve il certificato server dal sito falso».

Che cosa succede dentro il browser

HSTS (HTTP Strict Transport Security) è un meccanismo con cui il sito, con l’intestazione Strict-Transport-Security, dichiara «d’ora in poi su questo host vieni sempre in HTTPS», e il browser lo ricorda. Lo definisce RFC 6797⁸.

Quando si tenta di accedere con http:// a un host che si ricorda, il browser si muove così.

1. Sostituisce lo schema dell’URL da http a https. Se la porta 80 è esplicitata, la converte in 443 (RFC 6797, sezione 8.3)
2. Di conseguenza si collega in HTTPS. In quel momento il DNS è manipolato, quindi la destinazione è il sito falso
3. Riceve il certificato server dal sito falso
4. La verifica fallisce, e si arriva allo stesso errore del capitolo 4

L’importante è che la sostituzione di 1 è completata prima di uscire sulla rete. La richiesta HTTP in chiaro non viene nemmeno inviata. Per questo non si arriva alla situazione «mi sono collegato in HTTP, quindi il certificato non esce».

Non si può premere «ignorare e andare avanti»

HSTS ha un’altra proprietà, in pratica molto grande. La sezione 8.4 di RFC 6797, se durante l’istituzione di un canale di comunicazione sicuro con un host su cui HSTS è attivo si verifica un errore, sia avviso sia fatale, chiede di interrompere la connessione. E la sezione 12.1 esprime quel comportamento come “No User Recourse” (non dare all’utente un mezzo di aggiramento) e dice che non si deve offrire una scelta del tipo «questa connessione non è sicura, continuare?».

In un errore di certificato ordinario, molti browser preparano sulla schermata di avviso un percorso «impostazioni avanzate», «continuare». In pratica, la scena in cui un utente abituato all’errore di certificato di un sistema interno lo preme di riflesso non è rara. HSTS chiude quel riflesso. Come difesa contro un sito falso, si può persino dire che questo «non si può premere» funziona più della verifica del certificato in sé.

La premessa di HSTS — Il primo accesso non è protetto

HSTS, però, ha una premessa. Come definisce la sezione 8.1 di RFC 6797, un host diventa un «host HSTS noto» quando l’agente utente riceve l’intestazione Strict-Transport-Security su un canale di comunicazione sicuro. Cioè, quel browser deve essere arrivato almeno una volta al sito legittimo in HTTPS.

Quindi, nei casi seguenti, non si protegge.

• Su un PC aziendale appena distribuito, il primo accesso avviene subito sotto un AP falso
• Si è ricreato il profilo del browser, o si sono cancellati i dati di navigazione e anche il record HSTS
• La scadenza del record (max-age) era scaduta

A colmare questo problema del primo accesso è l’elenco di preload HSTS. Se si è nell’elenco di domini incorporato in anticipo nel browser, si forza HTTPS anche senza essersi mai collegati.

Se però considerate la registrazione del vostro sito, confermate prima le condizioni. I requisiti di registrazione sono i seguenti⁹.

• Fornire un certificato valido
• Se si è in ascolto sulla porta 80, reindirizzare da HTTP a HTTPS sullo stesso host
• Fornire tutti i sottodomini in HTTPS (incluso www se c’è un record DNS)
• Sul dominio di base, restituire un’intestazione Strict-Transport-Security con max-age di 31536000 secondi (1 anno) o più, includeSubDomains e preload

Ciò che conta è la combinazione del terzo e di includeSubDomains. Se un vecchio sottodominio interno era solo HTTP, o non aveva un certificato, nell’istante della registrazione non ci si arriva più. Prima della registrazione fate inventario di tutti i sottodomini.

E la revoca non è facile. Una richiesta di cancellazione in genere viene accettata, ma perché il cambio arrivi al browser dell’utente passano mesi, e per i browser diversi da Chrome non c’è garanzia⁹. Il preload non è un’impostazione «se sbagliamo, la riportiamo indietro»: è più sicuro avvicinarsi pensando così.

Dal lato di chi usa, se i servizi cloud usati nel lavoro supportano HSTS è un punto di conferma che si può mettere nella selezione.

6. Nell’istante in cui l’approvazione è vuota, la funzione di condivisione diventa un percorso di fuoriuscita — Domanda 2(1)

Da qui si passa all’esame della fuoriuscita da parte di un dipendente.

Il signor S conferma prima l’operazione della funzione di condivisione file. I superiori confermano davvero l’indirizzo e-mail del destinatario e il file prima di approvare? La risposta di Y è «sembra che ci siano superiori che non confermano».

Allora il signor S segnala la domanda 2(1). Si risponde in concreto, entro 40 caratteri, al metodo di abuso della funzione di condivisione file per rendere i file scaricabili da fuori della società M.

La risposta modello è «Specificare il proprio indirizzo e-mail privato come indirizzo e-mail del condivisore esterno».

Il progetto è corretto, l’operazione è vuota

La funzione di condivisione file del servizio B è fatta pensando bene.

• Per condividere serve l’approvazione del superiore
• Il collegamento di condivisione esterna non viene comunicato né alla persona né al superiore. Chi condivide non può inoltrare il collegamento e portarlo via
• Il collegamento contiene una stringa casuale difficile da indovinare, e la scadenza è un giorno

Soprattutto il secondo è un progetto consapevole della fuoriuscita dall’interno. Eppure si rompe. Se si mette se stessi come destinatario, il collegamento «non comunicato alla persona» arriva in mano alla persona.

E la condizione perché questo buco si apra è una sola: «il superiore non conferma il destinatario». Il flusso di approvazione è progettato sul presupposto che chi approva guardi il contenuto. Se non guarda, è solo un percorso di consegna automatizzato.

Le condizioni in cui l’approvazione si svuota sono decise

Quando in pratica l’approvazione si svuota, la causa è di solito una di queste.

Alla società M di questa domanda manca soprattutto le ultime due. Se mettete un meccanismo che fa passare l’approvazione, serve anche un meccanismo che dopo guarda il risultato dell’approvazione. Solo poter elencare quante condivisioni esterne verso un dominio di e-mail gratuita ci sono state in un mese rende questo trucco abbastanza più facile da trovare.

Il quadro complessivo di da dove una PMI dovrebbe partire è in Da dove iniziare con la sicurezza per le PMI? — Guida alla «Linea guida per la sicurezza informatica delle PMI» dell’IPA, 4ª edizione.

7. Il buco che è la sala riunioni — Domanda 2(2)

La domanda successiva del signor S è «in sala riunioni si può portare un PC di proprietà personale?». La risposta di Y è «portarlo in sala riunioni non è vietato, quindi si può».

Qui escono il metodo 1 e il metodo 2. Entrambi hanno la trama scaricare i file dal servizio B con un PC di proprietà personale e portare via quel PC di proprietà personale. Le impostazioni del software di prevenzione della fuoriuscita di informazioni messo sul PC aziendale non hanno alcun effetto su un PC di proprietà personale.

Metodo 1 — Spoofing dell’indirizzo MAC

Il metodo 1 è cambiare l’[e] indirizzo MAC dell’interfaccia wireless di un PC di proprietà personale in quello dell’interfaccia wireless di un PC aziendale, e poi collegare il PC di proprietà personale alla LAN wireless dei dipendenti. Rispondere allo spazio e è la domanda 2(2).

Ciò che proteggeva l’ingresso della LAN wireless dei dipendenti erano due cose: la pre-shared key di WPA2-PSK e il filtro MAC. Entrambe un dipendente le supera.

• La pre-shared key è impostata sul PC aziendale, e il dipendente è l’utente del PC aziendale. Dato che è un modo in cui tutti condividono una chiave, il presupposto è «l’utente può saperla»
• L’indirizzo MAC si riscrive sul lato dispositivo. Di solito si cambia dalle impostazioni del sistema operativo o dalle proprietà del driver, e non serve uno strumento speciale. Inoltre l’indirizzo MAC nei frame della LAN wireless non è cifrato, quindi ricevendo il segnale da vicino si può anche conoscere l’indirizzo MAC di un PC aziendale registrato

Filtro MAC e SSID non notificato hanno senso come riordino che riduce i collegamenti sbagliati. Non sono però un meccanismo di autenticazione che ferma chi vuole entrare di proposito. Confermate anche nella vostra configurazione se non avete messo questi due nel numero delle «contromisure».

Metodo 2 — Semplicemente collegarsi alla LAN wireless ospiti

Il metodo 2 è ancora più semplice. Collegare il PC di proprietà personale alla LAN wireless ospiti, scaricare i file dal servizio B e portare via il PC di proprietà personale. Tutto qui.

Non serve nemmeno lo spoofing dell’indirizzo MAC. Serve solo la pre-shared key della LAN wireless ospiti, e questa è ciò che si dà agli ospiti. Un dipendente non può non saperla.

Qui, ovviamente, esce il dubbio successivo. Il servizio B era ristretto a «con un ID utente assegnato a un dipendente della società M, l’accesso è possibile solo dall’indirizzo IP globale della società M», no?

Che cosa consente una restrizione per indirizzo IP di origine

Se si legge l’impostazione del firewall nel testo della domanda, la risposta esce. Anche le comunicazioni dalla LAN wireless ospiti verso Internet, come quelle dalla LAN wireless dei dipendenti, vengono convertite dallo stesso NAT nello stesso unico indirizzo IP globale.

Dal punto di vista del servizio B, questi tre non si distinguono. La restrizione per indirizzo IP passa dritta.

Questo schema, anche fuori dall’esame, ricompare. Una restrizione per indirizzo IP di origine non significa «solo da questo dispositivo». Significa «da tutti coloro che escono con questo indirizzo IP globale». Esempi classici in cui l’ambito che si pensava di consentire e l’ambito che viene davvero consentito si sfasano.

Non è che una restrizione per indirizzo IP di origine sia inutile. È che non si usa la restrizione da sola. Solo restringendo per indirizzo IP e poi sovrapponendo un meccanismo che identifica il dispositivo stesso (certificato client o certificato di dispositivo) e un meccanismo che identifica l’utente (autenticazione a più fattori) si esprime «questa persona, su questo dispositivo». Anche le contromisure di questa domanda vanno proprio in quella direzione.

8. Legare il dispositivo con un certificato — Domanda 3(1)–(4)

Come contromisura al metodo 1, la società M sceglie EAP-TLS come modo di autenticazione della LAN wireless dei dipendenti e prepara un server di autenticazione.

Domanda 3(1) — RADIUS

La domanda 3(1) chiede il protocollo su UDP usato dal server di autenticazione con EAP. La risposta modello è RADIUS.

Messo in ordine lo schema, i personaggi sono tre.

Tra PC aziendale e AP è IEEE 802.1X (EAP over LAN), tra AP e server di autenticazione è RADIUS. RADIUS gira su UDP¹⁰. La procedura di EAP-TLS in sé è definita da RFC 5216¹¹. Se si costruisce con Windows Server, il ruolo di server di autenticazione lo svolge Network Policy Server (NPS)¹².

Fissiamo che cosa cambia passando da WPA2-PSK a EAP-TLS.

L’ultima riga ha bisogno di una nota. In EAP-TLS, la controparte di cui il client verifica il certificato è il server di autenticazione, non l’AP. L’AP è solo un authenticator che inoltra lo scambio EAP, e il client non sta confermando l’identità dell’AP in sé.

Che ciò valga comunque come preparazione all’evil twin del capitolo 4 è perché il materiale di chiave generato solo al successo dell’autenticazione arriva solo a un AP legittimo che ha il segreto condiviso RADIUS. Un AP alzato a piacere da un attaccante, se non ha più avanti un server di autenticazione legittimo, non può portare questa procedura fino in fondo. Ciò che il client verifica direttamente è il server di autenticazione, e la legittimità dell’AP se ne deriva in modo indiretto: questa è la struttura.

È però condizionata. Se sul lato client non si imposta «di quale CA, di quale nome di certificato server ci si fida», quando l’attaccante prepara un proprio server di autenticazione non si distingue. Una configurazione in cui si è messo EAP-TLS ma nel profilo del client si è disabilitata la verifica del certificato server esiste davvero. Se lo introducete, confermate fino a lì.

Domanda 3(2) — La risposta sbagliata segnalata dal commento di valutazione

La spiegazione di Y continua così. Il certificato client lo emette un server CA di nuova istituzione, e il dipendente non lo installa da sé sul proprio PC aziendale: lo si memorizza sul PC aziendale con la funzione del server di directory. E il [f] corrispondente al certificato client si memorizza nel TPM del PC aziendale e si protegge, per [g].

La domanda 3(2) chiede lo spazio f. La risposta modello è chiave privata.

Il commento di valutazione scrive così.

La domanda 3(2) ha avuto un tasso di risposte corrette un po’ alto, ma in una parte si sono viste risposte come “chiave pubblica” o “certificato server”. La PKI è una tecnica importante, base di varie tecniche di sicurezza, quindi si vorrebbe che si capisse bene in quali scene e come viene usata.

La chiave pubblica è ciò che sta nel certificato e si distribuisce in tutto il mondo. Non è oggetto di protezione. Ciò che va protetto è la chiave privata che dovrebbe avere solo il titolare di quel certificato. «Autenticare con un certificato client», in termini precisi, è «dimostrare di avere la chiave privata corrispondente alla chiave pubblica nel certificato, firmando con quella chiave». Quindi se si può duplicare la chiave privata, l’autenticazione con certificato perde senso.

Cosa cambia se si mette nel TPM — Domanda 3(3)

La domanda 3(3) chiede lo spazio g entro 20 caratteri. La risposta modello è «in modo che non si possa estrarre dal PC aziendale».

Se si mette la chiave privata come file sul dispositivo, è un dato che si può copiare. Se la si copia su un PC di proprietà personale, quel PC di proprietà personale passa l’autenticazione come PC aziendale. Si pensava di chiudere il metodo 1 (spoofing dell’indirizzo MAC) e si sostituisce solo con lo «spoofing del certificato».

Il TPM può generare la chiave al suo interno e tenerla in uno stato in cui non si estrae. Operazioni come la firma avvengono dentro il TPM, e la chiave stessa non arriva né al sistema operativo né all’applicazione né a un malware. Di conseguenza, quella chiave privata si fissa a un pezzo fisico di quella macchina.

Su Windows, nel key storage provider (KSP) del modello di certificato si specifica Microsoft Platform Crypto Provider. Questo provider protegge la chiave usando il TPM, e se nel modello di certificato è spuntato «consentire l’esportazione della chiave privata» non si può scegliere¹³. Se si può esportare, proteggere non ha senso: un vincolo ovvio.

Il ruolo del pezzo TPM in sé è trattato, dal contesto della cifratura del disco, nella Guida pratica a BitLocker. Il modo di pensarla «non far uscire la chiave privata dal dispositivo» è la stessa idea del progetto dell’autenticatore spiegato in Perché le passkey sono sicure.

Perché si può dire «non c’è problema» — Domanda 3(4)

Sentita la spiegazione di Y, il signor S risponde «con quel modo di memorizzazione penso che non ci sia problema». La domanda 3(4) chiede il motivo, entro 40 caratteri.

La risposta modello è «Perché le informazioni di autenticazione necessarie a EAP-TLS si possono memorizzare solo sul PC aziendale».

Il flusso, seguito, è questo.

1. Il certificato client non lo installa il dipendente da sé: lo si distribuisce al PC aziendale con la funzione del server di directory. Non passa dalle mani del dipendente
2. La chiave privata è dentro il TPM e non si può estrarre dal PC aziendale
3. Quindi, a collegarsi in EAP-TLS alla LAN wireless dei dipendenti sono solo i PC aziendali distribuiti dall’azienda
4. Un PC di proprietà personale, anche spoofando l’indirizzo MAC, non passa l’autenticazione. Il metodo 1 è chiuso

Attenzione al modo condizionato «con quel modo di memorizzazione». Se la chiave privata fosse stata messa come file sul PC aziendale, il signor S non avrebbe detto che non c’è problema. Anche nella stessa «autenticazione con certificato client», l’ambito che si protegge cambia a seconda di dove si mette la chiave privata.

Ciò che il TPM non protegge

D’altra parte, non è che se lo si mette nel TPM si sta tranquilli. Ciò che il TPM garantisce è solo «quella chiave non viene duplicata su un altro dispositivo». Le cose seguenti non le protegge.

• Se si porta via il dispositivo stesso. Se si porta via il PC aziendale, si è portato via anche il TPM. Nelle regole della società M portare i PC aziendali fuori è vietato, ma regola e imposizione tecnica sono cose distinte. Servono a parte la cifratura del disco (compresa l’autenticazione prima dell’avvio) e un’operazione che revochi il certificato in caso di smarrimento
• L’impersonificazione dell’utente. Il TPM identifica il dispositivo, ma non garantisce chi sta operando su quel dispositivo. L’autenticazione dell’utente serve a parte
• Un malware che gira sul dispositivo. La chiave privata non si legge, ma il codice che gira su quel dispositivo può «chiedere al TPM di firmare». Si previene la duplicazione della chiave, non l’abuso mentre quel dispositivo è preso

9. Separare l’indirizzo IP di uscita — Domanda 3(5)

Come contromisura al metodo 2 (semplicemente collegarsi alla LAN wireless ospiti), la società M esamina due proposte. Cambiare l’impostazione NAT del FW, e usare un servizio di LAN wireless (servizio D).

La domanda 3(5) chiede il contenuto della modifica della prima, entro 70 caratteri. La risposta modello è nel senso di «Quando si accede a Internet dalla LAN wireless ospiti, rendere l’indirizzo IP di origine un indirizzo IP diverso da quello globale attualmente in uso» (nel testo della domanda quell’indirizzo IP globale è notato a1.b1.c1.d1).

Come si è visto nel capitolo 7, il metodo 2 si regge perché il traffico della LAN wireless ospiti esce con lo stesso indirizzo IP globale dei dipendenti. Allora basta convertire solo la LAN wireless ospiti in un altro indirizzo IP globale. La restrizione per indirizzo IP lato servizio B non si cambia, e solo l’accesso dalla LAN wireless ospiti ne esce.

Questo si regge perché sul lato WAN della società M sono assegnati più indirizzi IP globali. Se si legge l’impostazione di interfaccia del FW nel testo della domanda, la maschera di sottorete lato WAN è 255.255.255.248, cioè /29, e si capisce che gli indirizzi usabili non sono uno. Far leggere in dettaglio la tabella del testo della domanda: una premessa umile ma certa.

Se nella vostra azienda si può fare la stessa mossa dipende da se sulla linea in contratto si possono usare più indirizzi IP globali. Se ce n’è uno solo, questa proposta non si prende. In quel caso si passa alla proposta di separazione del capitolo successivo.

10. La contromisura arriva fino a cancellare le impostazioni che non si usano più — Domanda 3(6)(7)

All’esito dell’esame, la società M decide di usare il servizio D.

• In sala riunioni si colloca un router LAN wireless (router D) prestato dal servizio D
• Sul router D si abilitano la funzione di server DHCP e la funzione di server cache DNS
• I terminali portati dagli ospiti, senza passare dalla rete della società M, si collegano a Internet usando la SIM montata sul router D
• Il proiettore non usa più la LAN wireless ospiti: si cambia il metodo in collegamento con cavo HDMI

flowchart LR
    accTitle: Dopo le contromisure si stacca la rete ospiti
    accDescr: Per i dipendenti si usano EAP-TLS e TPM, e i terminali portati dagli ospiti escono in Internet con la SIM del router D senza passare dalla rete della società M
    subgraph M["Rete interna della società M (dopo le contromisure)"]
        direction TB
        E["LAN wireless dipendenti<br/>EAP-TLS + RADIUS<br/>la chiave privata è nel TPM"]
        S["Rete server"]
        FW["FW"]
        E --> FW
        S --> FW
    end
    subgraph K["Sala riunioni"]
        T["Terminale portato dall'ospite"]
        D["Router D<br/>su Internet diretto con SIM"]
        T --> D
    end
    FW --> B["Servizio B"]
    D --> I["Internet"]

Figura 3: La rete ospiti è staccata fisicamente e logicamente dalla rete della società M; non esce più nemmeno dallo stesso indirizzo IP globale.

La rete per gli ospiti è stata staccata, fisicamente e logicamente, dalla rete della società M. Non esce più nemmeno con lo stesso indirizzo IP globale.

Domanda 3(6) — Comunicazioni che non servono più

Quando i terminali portati dagli ospiti non usano più la rete della società M, le comunicazioni verso il server DHCP e il server [h], finora necessarie, non servono più. La risposta modello dello spazio h è DNS.

Il router D stesso ha funzione di server DHCP e di server cache DNS, quindi i terminali portati dagli ospiti non hanno più bisogno di usare il server DHCP e il server DNS nella rete server della società M. Se si rilegge la spiegazione del testo della domanda, è scritto così com’è.

Domanda 3(7) — Elencare tutte le impostazioni da cancellare

La domanda 3(7) fa rispondere, ciascuna per intero, ai numeri di voce da eliminare dall’impostazione di interfaccia VLAN del FW e dall’impostazione di filtro, in seguito a questo cambio.

La risposta è: dall’impostazione di interfaccia VLAN, la VLAN della LAN wireless ospiti (voce 1); dall’impostazione di filtro, la regola che consente HTTP/HTTPS da LAN wireless ospiti a Internet (voce 1) e la regola che consente l’accesso da LAN wireless ospiti al DNS della rete server (voce 4), due. Insieme, dalle impostazioni dell’AP si elimina l’impostazione dell’SSID ospiti.

Il commento di valutazione scrive così.

La domanda 3(7) ha avuto un tasso di risposte corrette alto. Bisognava rispondere capendo tutte le impostazioni di filtro del firewall e l’impatto della revisione dell’ambiente LAN wireless, e si era capito in modo adeguato.

È una domanda con un tasso di risposte corrette alto, ma le organizzazioni che in pratica arrivano fino a lì non sono molte. Al lavoro di mettere un meccanismo nuovo si allegano budget e scadenza; al lavoro di cancellare le impostazioni vecchie no. E la dimenticanza di cancellare esce in forme come le seguenti.

Il firewall di questa domanda è di un modo che valuta le regole in ordine dal numero di voce più piccolo e applica la prima che coincide (è scritto così nel testo della domanda). In questo modo, lasciare in alto una regola di consenso non più usata è lo stesso che lasciare aperto un buco perché non si arrivi alla regola di rifiuto in coda.

Non generalizzate però questo modo di valutazione a tutti i firewall. Il modo di decidere cambia da prodotto a prodotto.

In qualunque modo, che lasciare un consenso non usato sia pericoloso, in sé, non cambia. Cambia «perché è pericoloso» e «come si corregge». Confermate quale modo ha il vostro apparato e, nell’oggetto dell’inventario periodico, mettete il punto di vista «origine e destinazione esistono ancora?».

Il discorso del firewall host, come gestire le regole in ingresso necessarie lato app aziendale, è in Il firewall di Windows e le applicazioni aziendali.

11. Le contromisure che non hanno funzionato e quelle che hanno funzionato

Se si riassume questa domanda in un foglio, è la tabella seguente. La corrispondenza tra le contromisure che aveva la società M e i percorsi con cui sono state superate.

Solo l’ultima riga è «ha funzionato». E se si allineano le contromisure elaborate, è così.

Confrontando, la differenza di carattere è chiara. Le contromisure superate sono in molti casi il divieto di un «mezzo», e le contromisure che hanno funzionato e quelle elaborate cambiano «percorso» o «natura delle credenziali». Anche se si chiude la chiavetta USB, se resta un percorso verso i file la fuoriuscita si regge; anche se si allunga la pre-shared key, il fatto che sia un segreto condiviso non cambia.

12. Punti di conferma in pratica

Elenco le voci di conferma quando si applica questa domanda alla propria configurazione.

1. Si possono scrivere le contromisure alla fuoriuscita in percorsi, non in mezzi? Non un elenco di mezzi — chiavette USB, allegati e-mail, webmail — ma «l’elenco dei dispositivi e delle reti che possono arrivare ai file aziendali». Se c’è anche un solo percorso con cui un dispositivo fuori gestione può arrivare, il divieto dei mezzi viene aggirato
2. Le regole di portare e portare via non limitano il luogo? «Divieto di portare nell’area ufficio» sta consentendo sala riunioni, reception, spazi comuni. Confermare se il recinto fisico e il recinto di rete coincidono
3. Si sa dire l’ambito che una restrizione per indirizzo IP di origine consente davvero? Contare tutto ciò che esce con quell’indirizzo IP globale. Wi-Fi ospiti, rete ospiti, VPN tra sedi, gateway di aggregazione del telelavoro, ambiente di verifica
4. Le credenziali della LAN wireless sono per dispositivo? Una pre-shared key è un segreto condiviso che tutti hanno uguale: se uno la fa fuoriuscire fuoriesce quella di tutti, e non si può nemmeno fermare solo una macchina
5. Filtro MAC e SSID non notificato non sono messi nel numero delle contromisure? Entrambi sono un riordino che riduce i collegamenti sbagliati, non un’autenticazione
6. La chiave privata del certificato client è in uno stato in cui non si estrae dal dispositivo? Una chiave privata messa come file si può duplicare. Si specifica un key storage provider che usa il TPM e non si consente l’esportazione
7. Il client in cui avete messo EAP-TLS verifica il certificato del server di autenticazione? Se lo disabilitate, si perde la resistenza a un server di autenticazione falso
8. L’errore di certificato server non è in uno stato in cui l’utente lo supera con «continuare»? Sul proprio sito si imposta HSTS. Non si lascia l’errore di certificato di un sistema interno, e non si fa imparare all’utente che «l’errore è qualcosa da premere e andare avanti»
9. Si fa inventario del contenuto dell’archivio Autorità di certificazione radice attendibili? Ciò che ci sta è, in sé, la controparte a cui quel dispositivo dichiara «un certificato emesso da questa CA lo considero vero»
10. A chi approva nel flusso di approvazione arriva materiale di giudizio? E dopo si guarda il risultato dell’approvazione? Confermare periodicamente in elenco le condivisioni verso domini esterni e verso e-mail gratuite
11. Si cancellano le impostazioni dei percorsi aboliti? Interfaccia VLAN, regole di filtro, SSID, voci degli elenchi di consenso. Con lo stesso trattamento del lavoro di «mettere il nuovo», si mette una scadenza anche al lavoro di cancellare

In chiusura — Una contromisura che non ha scritto l’«ambito» non protegge

Se la domanda 1 chiedeva «quella contromisura ferma quale attacco, a quale stadio», ciò che chiede la domanda 2 è «quell’ambito quella contromisura protegge».

Ciascuna delle contromisure della società M aveva un ambito implicito. L’ambito del software di prevenzione della fuoriuscita di informazioni arriva fino al PC aziendale. L’ambito del divieto di portare arriva fino all’area ufficio. L’ambito del filtro MAC arriva fino a «una controparte che non spoofa». L’ambito della restrizione per indirizzo IP di origine arriva fino a «tutti coloro che escono con quell’indirizzo IP globale». Ciascun ambito funzionava correttamente: solo, il giunto con il vicino era vuoto.

Questa domanda è pratica perché la società M è disegnata come un’azienda che prendeva sul serio le contromisure. Dopo l’incidente dell’anno precedente ha chiuso entrambi gli estremi del percorso e ha messo anche un software dedicato. Che resti un buco non è perché i responsabili si erano rilassati: è perché, con un modo di aggiungere le contromisure una per una, lo spazio tra gli ambiti non si vede.

Per trovare lo spazio non resta che scrivere non l’elenco delle contromisure ma l’elenco dei percorsi. Ciò che facevano Y e il signor S in questa domanda è proprio quello. Separare «attaccante esterno» e «dipendente», e chiudere uno per uno i percorsi di arrivo. La «capacità di presupporre da vari angoli le minacce in un ambiente che usa una LAN wireless» che l’IPA ha scritto nello scopo della domanda è, probabilmente, questo lavoro.

Aree di consulenza correlate

KomuraSoft LLC si occupa di revisioni di progetto che presuppongono la rete e la configurazione dei dispositivi esistenti, e dell’implementazione della distribuzione dei certificati e della protezione delle chiavi in un ambiente Windows.

• Consulenza tecnica e revisione del progetto
• Sviluppo di applicazioni Windows
• Analisi dei bug e delle cause
• Contattaci

Riferimenti

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Abbiamo vietato le chiavette USB e vietato il salvataggio sul disco locale. Perché i file si possono ancora portare via?

Perché ciò che è stato vietato è una funzione del PC aziendale prestato dall'azienda, non il percorso di arrivo al posto in cui stanno i file. In questa domanda il dipendente usa il proprio PC di proprietà personale. Senza toccare affatto il PC aziendale, collega il PC personale alla LAN wireless della sala riunioni, accede all'archiviazione cloud (servizio B) con il proprio ID utente, scarica i file e porta via il PC personale stesso. Le impostazioni del software di prevenzione della fuoriuscita di informazioni messo sul PC aziendale non hanno alcun effetto su un PC di proprietà personale. La società M aveva vietato di portare PC di proprietà personale — ma il divieto copriva solo l'area ufficio; la sala riunioni era esclusa. Anche se si chiudono i mezzi uno per uno (chiavette USB, allegati e-mail, webmail), la fuoriuscita si regge finché resta un percorso che arriva ai file.

Il servizio B era ristretto a «accesso possibile solo dall'indirizzo IP globale della società M». Perché dal Wi-Fi ospiti si passa?

Perché anche il traffico della LAN wireless ospiti passa dallo stesso NAT dello stesso firewall e, convertito nello stesso indirizzo IP globale, esce su Internet. Dal punto di vista del servizio B, l'accesso da un PC aziendale interno e l'accesso da un PC di proprietà personale collegato alla LAN wireless ospiti in sala riunioni sembrano lo stesso indirizzo IP di origine. Non si distinguono. Una restrizione basata sull'indirizzo IP di origine va capita come un'impostazione che consente non «solo da questo dispositivo» ma «tutti coloro che condividono questa uscita». Wi-Fi ospiti, VPN tra sedi, gateway di aggregazione per il telelavoro: tutto ciò che esce con lo stesso indirizzo IP globale entra nell'ambito consentito.

Sulla LAN wireless dei dipendenti c'era un filtro degli indirizzi MAC. Non vale come contromisura?

No. Un indirizzo MAC si può riscrivere a piacere sul lato dispositivo. Il metodo 1 di questa domanda era cambiare l'indirizzo MAC dell'interfaccia wireless di un PC di proprietà personale in quello di un PC aziendale registrato, e poi collegarsi. L'indirizzo MAC nei frame della LAN wireless viaggia senza cifratura, quindi ricevendo il segnale da vicino si può anche conoscere un indirizzo MAC registrato. Lo stesso vale per l'SSID non notificato. Anche disabilitando la notifica dell'SSID, l'SSID si ricava dallo scambio quando un dispositivo si collega. Filtro MAC e SSID nascosto riducono gli collegamenti accidentali sbagliati, ma non sono un meccanismo di autenticazione che ferma chi vuole collegarsi di proposito.

Anche con un punto di accesso falso e un sito falso, perché si può dire che il dipendente non si fa ingannare?

Perché, finché ci si collega in HTTPS, un sito falso non può passare la verifica del certificato server. La figura 2 del testo della domanda elenca quattro voci che possono comparire come dettaglio dell'errore: non emesso da un'autorità di certificazione attendibile; il nome server scritto sul certificato è diverso dal nome server di destinazione; revocato; scaduto. Un attaccante non può ottenere un certificato legittimo per il nome di dominio del servizio B, quindi un certificato auto-firmato fallisce sul primo punto, e un certificato ottenuto legittimamente per il proprio dominio fallisce sul secondo. Secondo il commento di valutazione dell'IPA, il tasso di risposte corrette della domanda che chiedeva questo contenuto di verifica era basso. Queste quattro voci non hanno però la stessa forza. Ciò che ferma l'attacco sono le prime due (emittente e nome) e la scadenza: i browser le verificano sempre. La conferma di revoca, invece, dipende da implementazione e impostazione. Chrome, per esempio, di solito non fa conferme OCSP o CRL in linea; usa un elenco limitato chiamato CRLSet, il cui scopo principale è il blocco in emergenza. Non pensate che revocando si scarti per forza. E se sul PC aziendale è distribuito il certificato radice di una CA interna, e la chiave privata o la procedura di emissione di quella CA sono in mano all'attaccante, anche il primo controllo passa.

Cosa succede se si sbaglia l'URL e si scrive «http://»? Che cosa sta facendo HSTS?

Il browser sostituisce HTTP con HTTPS e poi si collega, quindi il risultato è di nuovo un errore di certificato server. HSTS è un meccanismo con cui il browser ricorda il contenuto di un'intestazione ricevuta l'ultima volta che si è collegato a quel sito in HTTPS. RFC 6797 chiede che, se l'URL per l'host di destinazione contiene lo schema http, l'agente utente lo sostituisca con https, convertendo la porta 80 in 443 se era esplicitata. In altre parole, la richiesta HTTP in chiaro non esce nemmeno sulla rete. Ancora più importante: se la verifica del certificato fallisce nella comunicazione con un host su cui HSTS è attivo, la specifica chiede di interrompere la connessione, sia avviso sia fatale. È scritto esplicitamente che non si deve offrire all'utente una scelta del tipo «questa connessione non è sicura, continuare?». HSTS, però, presuppone che quel browser sia arrivato almeno una volta al sito legittimo in HTTPS e abbia ricevuto l'intestazione. Non protegge se il primo accesso da un dispositivo nuovo finisce subito sul sito falso. A colmare questo primo accesso è l'elenco di preload incorporato nel browser.

Cosa cambia se si memorizza la chiave privata del certificato client nel TPM?

La chiave privata non si può più estrarre da quel PC aziendale. Una chiave privata messa come file sul dispositivo si copia su un PC di proprietà personale, e quel PC passa l'autenticazione come se fosse il PC aziendale. Se si genera la chiave dentro il TPM e la si tiene in uno stato non esportabile, operazioni come la firma avvengono solo dentro il TPM, e la chiave stessa non arriva né al sistema operativo né a un malware. Di conseguenza, a passare l'autenticazione EAP-TLS sono solo i PC aziendali distribuiti dall'azienda. È per questo che il signor S ha potuto dire «con quel modo di memorizzazione non c'è problema». Su Windows si specifica Microsoft Platform Crypto Provider come key storage provider del modello di certificato, e non si consente l'esportazione della chiave privata. Il TPM, però, protegge solo «la chiave non viene duplicata su un altro dispositivo»: chi ha fisicamente quel dispositivo può usarlo. Per smarrimento o furto del dispositivo servono a parte la cifratura del disco e la revoca del certificato.

Cosa si dovrebbe riportare nella pratica da questa domanda?

Quattro cose. Prima: pensare le contromisure alla fuoriuscita in termini di percorsi, non di mezzi. Chiudere uno per uno chiavette USB, allegati e-mail e webmail non serve se resta un dispositivo che può arrivare ai file. Seconda: scrivere l'ambito che una restrizione per indirizzo IP di origine consente davvero. Se il Wi-Fi ospiti o una VPN usano la stessa uscita, anche quello è ambito consentito. Terza: rendere le credenziali della LAN wireless per dispositivo. Una pre-shared key è un segreto condiviso che tutti hanno uguale, quindi se uno la fa fuoriuscire fuoriesce quella di tutti. Con EAP-TLS e certificati client, e una configurazione in cui la chiave privata non esce dal TPM, le credenziali si fissano al dispositivo. Quarta: cancellare le impostazioni che non si usano più. L'ultima domanda di questo problema chiede di elencare tutte le impostazioni di interfaccia VLAN e le regole di filtro del firewall che restano dopo l'abolizione della LAN wireless ospiti — e secondo il commento di valutazione dell'IPA il tasso di risposte corrette era alto, ma le organizzazioni che in pratica arrivano fino a lì non sono molte.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.