La conformità per il WiFi senza password: HIPAA, PCI, ISO 27001

La rete WiFi senza password, ovvero lo standard 802.1X con EAP-TLS basato su certificati, non è obbligatoria per HIPAA, PCI-DSS 4.0 o ISO 27001:2022. Tutti e tre i framework prevedono un'identificazione univoca, una crittografia avanzata, una revoca tempestiva e registri di audit. Una password condivisa presenta criticità sotto ognuno di questi aspetti. I certificati per singolo dispositivo soddisfano ciascuno di questi requisiti fin dalla loro progettazione e generano i log analizzati dai revisori.

Cosa significa concretamente la conformità per il WiFi senza password?

Il WiFi senza password sostituisce una password di rete condivisa con una credenziale univoca per ciascun dispositivo o utente. Nelle reti aziendali, questo si traduce solitamente nello standard IEEE 802.1X, lo standard per il controllo dell'accesso alla rete basato su porta. Lo standard 802.1X affida la decisione a un server RADIUS. RADIUS è il protocollo utilizzato dagli access point per verificare con un server di autenticazione se un dispositivo può connettersi alla rete.

Il metodo più sicuro è EAP-TLS (Extensible Authentication Protocol con Transport Layer Security). Sia il dispositivo che il server presentano certificati digitali. Non esiste alcuna password da poter sottrarre tramite phishing, condividere o scrivere sulla lavagna della sala personale. Ogni sessione genera le proprie chiavi di crittografia secondo gli standard WPA2-Enterprise o WPA3-Enterprise.

È opportuno segnalare due metodi correlati:

• PEAP (Protected EAP) con nome utente e password fa parte dello standard 802.1X, ma non è un sistema senza password. Eredita infatti ogni vulnerabilità legata alla password sottostante.
• iPSK (identity pre-shared key) assegna a ciascun dispositivo la propria chiave su un unico nome di rete. Rappresenta un ponte pratico per i dispositivi che non possono ospitare un certificato.

La "conformità del WiFi senza password" è la risposta a una domanda fondamentale: la modalità con cui il personale e i dispositivi accedono alla rete soddisfa i controlli di accesso, crittografia e registrazione rispetto ai quali venite verificati? Nessuno dei tre framework presenti in questa guida menziona esplicitamente EAP-TLS. Tutti e tre descrivono tuttavia requisiti che una password condivisa rende difficili da dimostrare.

Perché una password WiFi condivisa non supera un audit?

Una chiave pre-condivisa (PSK) è un unico segreto noto a chiunque utilizzi la rete. Questo singolo aspetto crea quattro problemi in fase di audit:

• Nessuna attribuzione. Ogni dispositivo esegue l'autenticazione con lo stesso segreto. I log mostrano un indirizzo MAC e non una persona, e gli indirizzi MAC possono essere contraffatti.
• La revoca richiede la rotazione. Rimuovere un utente che lascia l'azienda significa dover cambiare la chiave su ogni singolo dispositivo. Il requisito 2.3.2 di PCI-DSS rende obbligatoria tale rotazione sulle reti collegate ai dati delle carte di pagamento.
• Raggio d'azione dell'impatto elevato. Una chiave trapelata compromette l'intera rete e spesso ogni sede che la condivide.
• Prove scarse. Non è possibile dimostrare a un revisore chi conosceva la chiave, quando l'ha appresa o se l'ex personale ne sia ancora in possesso.

L'accesso basato su certificati ribalta ognuno di questi punti. Ogni connessione porta con sé un'identità univoca. Revocare un certificato o disabilitare un account rimuove un singolo dispositivo o una singola persona. Nessuno conosce una chiave d'accesso, quindi nessuno può portarla con sé quando lascia l'azienda.

In che modo il WiFi basato su certificati soddisfa i requisiti PCI-DSS 4.0?

Lo standard PCI-DSS v4.0 è diventato l'unica versione attiva quando la v3.2.1 è andata in pensione il 31 marzo 2024. I suoi requisiti con data futura sono diventati obbligatori il 31 marzo 2025. La revisione limitata v4.0.1, pubblicata a giugno 2024, utilizza gli stessi numeri di requisito indicati di seguito.

Il WiFi senza password è conforme allo standard PCI?

Non da solo. La conformità PCI appartiene all'ambiente valutato, non a un prodotto. Il WiFi senza password soddisfa o semplifica i requisiti che le password condivise rendono complessi:

• 1.3.3 richiede controlli di sicurezza di rete tra ogni rete wireless e l'ambiente dei dati dei titolari di carta (CDE). Il CDE è l'insieme di sistemi che memorizzano, elaborano o trasmettono i dati delle carte. Il traffico wireless verso il CDE deve essere negato per impostazione predefinita. L'accesso basato sull'identità colloca i dispositivi autorizzati su una VLAN (LAN virtuale) specifica e nega tutto il resto.
• 2.3.1 e 2.3.2 richiedono la modifica delle chiavi wireless predefinite del fornitore. È inoltre necessario modificare le chiavi di crittografia wireless ogni volta che qualcuno che le conosceva lascia l'azienda. Con EAP-TLS nessuna persona conosce una chiave, quindi l'evento di attivazione per la partenza del personale non si verifica mai.
• 4.2.1.2 richiede una crittografia forte per l'autenticazione e la trasmissione sulle reti wireless che trasportano dati di carte o collegate al CDE. Lo standard PCI-DSS vieta il WEP dal 2010. L'autenticazione reciproca dei certificati con WPA2-Enterprise o WPA3-Enterprise soddisfa questo requisito.
• 8.2.2 limita gli account condivisi e generici a casi eccezionali con giustificazione documentata. Una password di rete condivisa da 200 dipendenti è difficile da giustificare.
• 8.2.5 richiede che l'accesso per il personale licenziato venga revocato immediatamente. Disattivare un account nel proprio provider di identità consente di ottenere questo risultato.
• 10.2.1 e 10.5.1 richiedono registri di audit, conservati per 12 mesi con i tre mesi più recenti immediatamente disponibili. I log RADIUS da 802.1X associano ogni connessione a un certificato o a un account.

Il WiFi senza password non copre il Requisito 11.2.1. Tale requisito richiede di verificare la presenza di punti di accesso autorizzati e non autorizzati almeno una volta ogni tre mesi. Questo rimane un compito dell'utente, come spiegato nella sezione dei limiti.

Lo standard HIPAA richiede il WiFi basato su certificati?

No. La HIPAA Security Rule (45 CFR Parte 164, Sottoparte C) è neutrale dal punto di vista tecnologico e non nomina alcun protocollo wireless. Stabilisce standard e specifiche di implementazione, alcune "richieste" e altre "indirizzabili". Indirizzabile significa che si implementa la specifica laddove ragionevole e appropriato. In caso contrario, si documenta il motivo e si adotta un'alternativa equivalente.

Il WiFi basato su certificati si mappa chiaramente sulle tutele tecniche della sezione §164.312:

• Identificazione univoca, §164.312(a)(2)(i), richiesto. Ogni dispositivo e persona sulla rete ha un'identità distinta.
• Crittografia e decrittografia, §164.312(a)(2)(iv), indirizzabile. Le chiavi per sessione proteggono le ePHI (informazioni sanitarie protette elettroniche) in transito nell'aria.
• Controlli di audit, §164.312(b), richiesto. I log RADIUS registrano quale identità si è connessa, da quale access point e quando.
• Autenticazione di persone o entità, §164.312(d), obbligatoria. Un certificato dimostra che il dispositivo è quello dichiarato. Collegarlo a un account di un provider di identità estende tale prova alla persona.
• Sicurezza della trasmissione, §164.312(e)(1). I controlli di integrità e la crittografia sono entrambi requisiti affrontabili in base a questo standard.

Anche le misure di salvaguardia amministrativa sono importanti. L'analisi dei rischi di cui al §164.308(a)(1)(ii)(A) è il punto in cui registrare il motivo per cui i controlli wireless sono ragionevoli. Le procedure di disattivazione di cui al §164.308(a)(3)(ii)(C) sono più facili da dimostrare quando la disattivazione di un singolo account rimuove l'accesso alla rete.

Attenzione alla direzione di marcia. Nel gennaio 2025, il Dipartimento della Salute e dei Servizi Umani degli Stati Uniti (HHS) ha pubblicato una proposta di regolamento. Questa eliminerebbe la maggior parte della distinzione tra requisiti obbligatori e affrontabili. Renderebbe inoltre obbligatorie la crittografia e l'autenticazione a più fattori, con limitate eccezioni. Si tratta di una proposta, non di una norma definitiva. L'accesso basato su certificati si trova già dalla parte corretta della barricata.

Cosa dice la norma ISO 27001 sul wireless?

La norma ISO/IEC 27001:2022 non prevede un controllo denominato "wireless". L'Appendice A elenca 93 controlli suddivisi in quattro temi, e diversi di essi si applicano direttamente alle modalità di connessione del personale a una rete. La norma ISO/IEC 27002:2022, che contiene le linee guida per l'attuazione, affronta il wireless nel controllo 8.22. Evidenzia che i perimetri wireless sono definiti in modo vago. Per gli ambienti sensibili, suggerisce di trattare l'accesso wireless come una connessione esterna fino al superamento di un gateway.

I controlli che un auditor verificherà:

• 5.15 Controllo degli accessi e 5.18 Diritti di accesso. Regole per stabilire chi può connettersi e come tale accesso viene fornito e rimosso.
• 5.16 Gestione delle identità e 5.17 Informazioni di autenticazione. Identità e segreti gestiti lungo il loro intero ciclo di vita. Una password condivisa è un'informazione di autenticazione che non è possibile attribuire a una singola persona.
• 8.5 Autenticazione sicura. Tecnologia di autenticazione adeguata alla sensibilità dell'accesso.
• 8.15 Registrazione e 8.16 Attività di monitoraggio. Log che registrano gli eventi ed evidenze che qualcuno li verifichi.
• 8.20 Sicurezza delle reti, 8.21 Sicurezza dei servizi di rete e 8.22 Segregazione delle reti.
• 8.24 Uso della crittografia.
• 5.19 e 5.23. Relazioni con i fornitori e servizi cloud, che si applicano se l'autenticazione viene eseguita come servizio cloud.

Le organizzazioni certificate ISO/IEC 27001:2013 avevano tempo fino al 31 ottobre 2025 per effettuare la transizione. Se la Dichiarazione di Applicabilità utilizza ancora la numerazione del 2013, come A.9 o A.13, è necessario aggiornarla.

Come i tre framework si collegano al WiFi senza password

Controllo	Framework	Cosa richiede	Password condivisa (PSK)	Basato su certificati (EAP-TLS)
1.3.3	PCI DSS 4.0	Default-deny tra wireless e il CDE	Ogni dispositivo associato alla chiave finisce in un unico segmento	VLAN per singola identità, blocco per impostazione predefinita
2.3.2	PCI DSS 4.0	Modifica delle chiavi wireless quando chiunque le conosca lascia l'azienda	Rotazione su ogni utente uscente, su ogni dispositivo	Nessuna persona possiede una chiave; è sufficiente revocare un singolo certificato
4.2.1.2	PCI-DSS 4.0	Crittografia forte per l'autenticazione e la trasmissione wireless	La robustezza dipende dalla qualità della passphrase	Certificati mutuali, chiavi per sessione
8.2.2	PCI-DSS 4.0	Account condivisi solo per eccezioni documentate	Condivisi per progettazione	Una credenziale per dispositivo o persona
10.5.1	PCI-DSS 4.0	12 mesi di log, tre mesi immediatamente disponibili	I log mostrano solo gli indirizzi MAC	I log nominano il certificato o l'account
§164.312(a)(2)(i)	HIPAA	Identificazione univoca (richiesta)	Non soddisfatta dalla credenziale di rete	Soddisfatta per progettazione
§164.312(b)	HIPAA	Controlli di audit (richiesti)	Attribuzione debole	Ogni sessione è attribuibile
§164.312(e)(1)	HIPAA	Sicurezza della trasmissione	Crittografata, ma chiave nota a tutto il personale	Crittografata con chiavi che nessuna persona conosce
5.17	ISO 27001:2022	Informazioni di autenticazione assegnate e gestite	Non assegnabili a una sola persona	Rilasciate, rinnovate e revocate per identità
5.18	ISO 27001:2022	Diritti di accesso forniti e rimossi	La rimozione richiede un cambio di chiave a livello di rete	La rimozione segue l'identity provider
8.22	ISO 27001:2022	Segregazione delle reti	Un segmento per chiave	Segmento per ruolo o tipo di dispositivo

Quali prove richiederà un auditor?

Gli auditor verificano la progettazione, la configurazione e il funzionamento. La progettazione è rappresentata dai diagrammi. La configurazione dagli esportabili. Il funzionamento dai log e dai campioni. Prepara il pacchetto prima del lavoro sul campo, non durante.

Elemento di prova	Cosa dimostra	PCI-DSS 4.0	HIPAA	ISO 27001:2022
Diagrammi di rete e di flusso dati che mostrano i confini per personale, ospiti e CDE	Progettazione della segmentazione	1.2.3, 1.2.4	§164.308(a)(1)	8.20, 8.22
Regole del firewall o ACL tra le VLAN wireless del personale e il CDE	Negazione predefinita nella pratica	1.3.3	§164.312(e)(1)	8.22
Esportazione della configurazione SSID che mostra la modalità Enterprise ed EAP-TLS	Autenticazione e crittografia forti	4.2.1.2	§164.312(a)(2)(iv)	8.5, 8.24
Politica dei certificati: CA emittente, periodo di validità, rinnovo, revoca	Ciclo di vita delle informazioni di autenticazione	4.2.1.2	§164.312(d)	5.17
Campione di chi ha lasciato l'azienda: tempo di disattivazione dell'account rispetto all'ultima autenticazione di rete	Revoca tempestiva	8.2.5	§164.308(a)(3)(ii)(C)	5.18
Log RADIUS con impostazioni di conservazione	Attribuzione e conservazione	10.2.1, 10.5.1	§164.312(b)	8.15
Inventario degli access point e risultati delle scansioni trimestrali dei rogue AP	Controllo degli access point autorizzati e non autorizzati	11.2.1, 11.2.2	§164.308(a)(1)	8.16
Certificati e contratti dei fornitori	Garanzia di terze parti	12.8	§164.308(b) dove il fornitore gestisce ePHI	5.19, 5.23

Come dimostrare i controlli WiFi a un auditor?

Esegui tu stesso il test su chi ha lasciato l'azienda come prima cosa. È il test che una password condivisa non può superare in modo pulito.

1. Esporta l'elenco delle risorse umane relative a chi ha lasciato l'azienda durante il periodo di audit.
2. Seleziona un campione, ad esempio da 10 a 25 persone in diverse sedi.
3. Per ciascuna di esse, estrai l'ora di disattivazione dell'account dal tuo identity provider.4. Estrai l'ultima autenticazione di rete andata a buon fine per quella identità dai log RADIUS.
4. Qualsiasi autenticazione successiva all'orario di disattivazione costituisce un rilievo. Correggi la causa prima che se ne accorga l'auditor.

Su una rete PSK, il punto quattro non restituisce informazioni utili. Nessun log associa una connessione alla persona che ha lasciato l'azienda, quindi non puoi dimostrare che abbia smesso di connettersi.

Come si colloca il WiFi senza password rispetto ai tuoi sistemi esistenti?

Non hai bisogno di nuovi access point. 802.1X è una funzionalità standard degli access point enterprise. Purple è indipendente dall'hardware e funziona come un overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.

Purple Staff WiFi utilizza reti basate sull'identità (Identity-Based Networks). L'accesso alla rete segue il tuo identity provider: Microsoft Entra ID, Okta o Google Workspace. I neoassunti ottengono l'accesso al momento della creazione del proprio account. Chi cambia ruolo cambia segmento di rete in base al nuovo profilo. Chi lascia l'azienda perde l'accesso quando l'account viene disattivato. Questo flusso di onboarding, mobilità e offboarding (JML) è ciò che produce prove chiare per PCI DSS 8.2.5, HIPAA §164.308(a)(3)(ii)(C) e il controllo ISO 27001 5.18.

La tua rete ospiti rimane separata. Lo standard PCI DSS 1.3.3 si applica ad essa tanto quanto alle reti del personale: il traffico degli ospiti verso il CDE deve essere negato. I piani Guest WiFi di Purple garantiscono la conformità GDPR e CCPA per i dati dei visitatori, come dettagliato in Connect vs Capture.

Per il tuo registro fornitori, Purple possiede le certificazioni ISO 27001 e Cyber Essentials ed è conforme a GDPR e CCPA. I dati della piattaforma Purple mostrano un uptime del 99.999% in oltre 80.000 sedi attive. Il tuo auditor considererà questi dati come una garanzia sul fornitore, non come prova dei tuoi controlli interni.

Come si presenta in pratica la conformità del WiFi senza password?

I tre scenari seguenti sono esempi pratici. Ognuno dichiara le proprie ipotesi, in modo da poter ricalcolare le cifre per la tua realtà aziendale.

Un hotel da 200 camere: eliminare la rotazione delle chiavi PCI

Situazione. Un hotel da 200 camere gestisce 140 dipendenti su un'unica rete PSK. I PC della reception e i tablet del ristorante su quella rete raggiungono il sistema di pagamento, il che la include nell'ambito PCI. Ipotizziamo un turnover annuale del personale del 30%, ovvero 42 persone che lasciano l'azienda all'anno.

Cosa è stato fatto. La rete del personale è passata a 802.1X con EAP-TLS, collegata all'identity provider del gruppo alberghiero. I dispositivi di pagamento sono stati spostati su una VLAN dedicata con regole di negazione predefinite da ogni altra rete. La rete ospiti è stata isolata da entrambe.

Risultato. Le rotazioni delle chiavi richieste dal requisito 2.3.2 scendono da 42 all'anno (ognuna delle quali interessava ogni singolo dispositivo del personale) a zero. Ogni persona che lascia l'azienda viene rimossa disattivando un singolo account. Il campione dei dipendenti usciti ha ora un log con cui effettuare il confronto. Gli operatori nel settore degli Hotels con personale stagionale registrano la riduzione più significativa, poiché il turnover è il fattore che impone la rotazione.

Una catena di negozi con 40 punti vendita: ridurre il raggio d'azione dell'impatto

Situazione. Una catena con 40 punti vendita utilizza una sola PSK in tutti i negozi per gli scanner di inventario portatili e i laptop del back-office. I direttori dei negozi conoscono la chiave. Un ex direttore la pubblica online.

Cosa è stato fatto. I laptop aziendali gestiti sono passati a EAP-TLS con certificati emessi tramite la gestione dei dispositivi. Gli scanner che non potevano ospitare certificati sono passati a iPSK, con una chiave per dispositivo, su una VLAN limitata. L'inventario degli access point di ciascun punto vendita è stato documentato in conformità con il Requisito 11.2.2.

Risultato. Il rischio derivante da una singola credenziale trapelata scende da 40 punti vendita a un unico dispositivo. La revoca di quel dispositivo richiede una sola azione e lascia gli altri scanner connessi. La catena di negozi può ora mostrare a un valutatore un inventario per singolo dispositivo anziché un'unica chiave condivisa. Lo stesso modello si adatta a qualsiasi realtà del settore Retail con un mix di dispositivi gestiti e headless.

Un dipartimento sanitario di contea: attribuzione HIPAA in 12 cliniche

Situazione. Un dipartimento sanitario di una contea statunitense gestisce 12 cliniche. I medici utilizzano tablet condivisi per accedere alla cartella clinica elettronica. Ciascuna clinica ha la propria password di rete, con il risultato di avere 12 credenziali condivise e nessuna attribuzione nei log di rete.

Cosa è stato fatto. I tablet hanno ricevuto certificati di dispositivo. I medici accedono con il proprio account dell'identity provider, in modo che ogni sessione colleghi un dispositivo a una persona. I log RADIUS alimentano il sistema di gestione dei log del dipartimento. Il periodo di conservazione è stato impostato in base al periodo di documentazione di sei anni previsto dalla sezione §164.316(b)(2), in cui il dipartimento classifica i log come documentazione.

Risultato. Le credenziali di rete condivise scendono da 12 a zero. L'analisi dei rischi può registrare le specifiche di crittografia come implementate anziché documentare un'alternativa. I controlli di audit ai sensi della sezione §164.312(b) mostrano ora quale persona, su quale dispositivo, si è connessa alla rete di quale clinica e quando. I team del settore Healthcare pubblico che rispondono sia a HIPAA sia agli audit statali possono riutilizzare lo stesso pacchetto di prove. I dispositivi del personale a bordo dei Trains seguono lo stesso modello, con un'unica identità per tablet in ogni carrozza e deposito.

Quali sono i limiti da conoscere?

• Non si tratta di un certificato di conformità. Il WiFi senza password soddisfa controlli specifici. L'ambito di applicazione, l'analisi dei rischi e il resto di ciascun framework rimangono di vostra responsabilità.
• I rogue access point richiedono ancora test. Lo standard PCI DSS 11.2.1 richiede test trimestrali per individuare access point autorizzati e non autorizzati. L'accesso basato su certificati non rileva un dispositivo non autorizzato collegato allo switch di un negozio.
• I certificati scadono. Sono necessari un'autorità di certificazione, un metodo di registrazione e un processo di rinnovo. Un rinnovo mancato scollega ogni dispositivo il cui certificato condivide tale data di scadenza.
• Non tutti i dispositivi possono ospitare un certificato. Stampanti, scanner e alcune apparecchiature cliniche non possono farlo. Utilizzate iPSK o una rete segmentata e documentate l'eccezione.
• PEAP non è una scorciatoia. PEAP con password mantiene i rischi legati alle password. Se i dispositivi non convalidano il certificato del server, un access point contraffatto può intercettare le credenziali.
• I log sono utili solo se conservati e analizzati. Impostate la conservazione a 12 mesi per PCI DSS. Dimostrate una cadenza di revisione per il controllo 8.16 di ISO 27001.

Cosa fare ora?

1. Classifica ogni nome di rete. Contrassegna quali interessano il CDE, l'ePHI o nessuno dei due. Questo decide quale framework si applica a ciascuno.
2. Esegui subito il test sul personale uscente. Se non riesci a completarlo, hai trovato il tuo primo rischio di audit.
3. Scegli una credenziale per classe di dispositivo. EAP-TLS per laptop, telefoni e tablet gestiti. iPSK per dispositivi headless.
4. Aggiorna la documentazione di controllo. Mappa la modifica nel tuo Dichiarazione di Applicabilità, nell'analisi dei rischi HIPAA o nel documento di definizione dell'ambito PCI DSS.
5. Fai un progetto pilota su un sito. Dimostra la registrazione dei certificati, l'assegnazione della VLAN e la revoca per il personale uscente prima di estendere la soluzione a tutta la rete aziendale.
6. Costruisci il pacchetto di prove. Utilizza la tabella delle prove sopra come checklist, tre mesi prima del lavoro sul campo.

Domande frequenti

Il WiFi senza password è conforme a PCI?

Il WiFi senza password non è conforme a PCI di per sé, poiché il PCI DSS valuta il tuo ambiente piuttosto che un singolo prodotto. Tuttavia, soddisfa i requisiti 2.3.2, 4.2.1.2, 8.2.2 e 8.2.5 in modo più pulito rispetto a una password condivisa, e i suoi log RADIUS supportano il requisito 10. È comunque necessario implementare controlli di tipo default-deny tra le reti wireless e l'ambiente dei dati dei titolari di carta ai sensi del requisito 1.3.3, oltre a test trimestrali sui rogue access point ai sensi dell'11.2.1.

L'HIPAA richiede il WiFi basato su certificati?

No, l'HIPAA non nomina alcuna tecnologia wireless specifica. La Security Rule richiede l'identificazione univoca, controlli di audit e l'autenticazione di persone o entità, e tratta la crittografia come un elemento da affrontare. Il WiFi basato su certificati soddisfa tutti questi requisiti per progettazione, il che rende la tua analisi dei rischi più facile da difendere. Una proposta di regolamento dell'HHS di gennaio 2025 renderebbe obbligatorie la crittografia e l'autenticazione a più fattori con limitate eccezioni. Si tratta di una proposta, non di una norma definitiva.

Cosa dice lo standard ISO 27001 sul wireless?

Lo standard ISO/IEC 27001:2022 non prevede un controllo specifico per il wireless. Gli auditor testano il wireless rispetto ai controlli dell'Appendice A da 5.15 a 5.18 per l'accesso e l'identità, 8.5 per l'autenticazione sicura, 8.15 per la registrazione dei log e da 8.20 a 8.22 per la sicurezza e la segregazione della rete. La guida ISO/IEC 27002:2022 al punto 8.22 suggerisce di trattare l'accesso wireless in ambienti sensibili come una connessione esterna finché non passa attraverso un gateway.

Come posso dimostrare i controlli WiFi a un auditor?

Puoi dimostrare i controlli WiFi tramite la configurazione, i log e un test sul personale uscente. Prepara diagrammi di rete che mostrino i confini del wireless e del CDE, esportazioni degli SSID che mostrino l'autenticazione Enterprise, la tua policy sui certificati, 12 mesi di log RADIUS e i risultati delle scansioni trimestrali dei rogue access point. Successivamente, esegui un test a campione sul personale uscente, confrontando l'ora di disattivazione dell'account di ciascun ex dipendente con la sua ultima autenticazione di rete andata a buon fine. Qualsiasi autenticazione successiva alla disattivazione rappresenta una non conformità rilevata.

Il Purple Staff WiFi funziona con i nostri access point esistenti?

Sì, Purple è agnostico rispetto all'hardware e funziona come un overlay cloud su Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Mantieni i tuoi access point e switch. Purple collega l'accesso alla rete a Microsoft Entra ID, Okta o Google Workspace, quindi l'abbandono di una password condivisa non richiede un progetto di sostituzione radicale dell'hardware.

E per i dispositivi che non possono ospitare un certificato?

Utilizza iPSK o una rete separata e segmentata per questi dispositivi. iPSK assegna a ciascun dispositivo la propria chiave sullo stesso nome di rete, quindi la revoca di un dispositivo lascia gli altri connessi. Colloca i dispositivi headless come stampanti e scanner su una VLAN limitata. Documenta la giustificazione aziendale nella tua analisi dei rischi o nella Dichiarazione di Applicabilità e rivedi ogni eccezione a ogni ciclo di audit.

La certificazione ISO 27001 di Purple ci rende conformi?

No, la certificazione di un fornitore non si trasferisce alla tua azienda. Le credenziali ISO 27001, Cyber Essentials, GDPR e CCPA di Purple costituiscono prove utili per la valutazione dei fornitori ai sensi dei controlli ISO 27001 5.19 e 5.23 e del requisito PCI-DSS 12.8. Il tuo perimetro, l'analisi dei rischi, la configurazione e i log devono comunque soddisfare ciascun framework, e il tuo auditor li verificherà direttamente.