Design del prodotto e sicurezza delle informazioni

Avete mai pensato che la sicurezza delle informazioni di un prodotto inizia in fase di progettazione? Per molti designer, questo può sembrare strano, ma è vero.I designer di prodotti gettano le basi per la sicurezza degli account, dei dati personali e del denaro degli utenti. Naturalmente, la sicurezza delle informazioni (IS) non è loro responsabilità; la maggior parte dei problemi sorgono durante lo sviluppo. Ma se un designer non riesce a prevedere potenziali insidie, gli sviluppatori probabilmente non riusciranno a gestirle correttamente.
Questo articolo non è una guida completa su come evitare tutti i possibili difetti IS e decisioni sbagliate durante la progettazione del prodotto. Tutti i progetti sono unici, dopotutto. Vogliamo solo mostrarvi come dovreste pensare e quali domande relative all’IS dovreste porre a voi stessi e agli sviluppatori durante la progettazione di un prodotto digitale.

Scenari

Tutto inizia con gli scenari. Iscriviti, accedi e reimposta la password. Pagamenti, aggiunta carte di credito e ricariche saldo. Modifica dei dati del profilo, aggiunta di nuovi dipendenti ed esportazione dei dati. Questi sono solo una manciata di scenari potenzialmente vulnerabili. E ogni progetto ha molti di questi scenari. Se pensate che fare come fanno gli altri sia abbastanza, abbiamo una brutta notizia.
Prendete uno scenario di verifica dell’autorizzazione. Se un designer non riesce a pensarci bene, spiegartelo in dettaglio nelle specifiche di progettazione o disegnare un rispettivo schermo, le probabilità che gli sviluppatori dimentichino importanti casi sono molto alte.

Voi non dovreste mai dimenticare di guardare ogni scenario dal punto di vista della sicurezza. In caso di dubbio, discuterne con il team di sviluppo.

Esempio 1

Prendiamo quello classico: reimpostazione della password.

Lo scenario è piuttosto semplice. Un utente:

Dimentica la password.
Fare clic su Reimposta password.
Ottiene un’e-mail di reimpostazione della password.
Segue un collegamento speciale dall’e-mail.
Inserisce una nuova password.
Ottiene l’autorizzazione nel sistema.

Quali schermi realizzerebbe un designer per questo scenario? Supponiamo di avere a che fare con un professionista, che pensa non solo alle schermate predefinite ma anche a tutti i possibili stati, come gli errori, per esempio. Il nostro professionista comprende che quando l’utente invia il modulo, il server può essere inattivo. O che l’utente possa inserire un indirizzo email non valido. E che dovremmo visualizzare un messaggio sull’invio di un collegamento di ripristino.
Quindi, otteniamo tre gruppi di schermate:

Schermata di reimpostazione della password in quattro stati: predefinita, compilata con errori, e-mail inviata, invio e-mail non riuscito.
L’email.
La schermata di immissione della password negli stessi quattro stati.

Ok, qual è il prossimo passo?
Gli schermi passano allo sviluppo. Supponiamo di avere uno sviluppatore, che fa il lavoro rigorosamente in base al compito senza pensarci troppo. Questo è solo uno scenario tipico, niente di cui preoccuparsi.
Ma non è tutto così semplice, in effetti. Immagina che l’utente sia passato attraverso lo scenario e abbia ripristinato il proprio accesso, ma il collegamento di ripristino sia trapelato a una terza parte (dannosa). Questo può accadere in molti modi, ma lo restringeremo a quello più popolare: un hotspot Wi-Fi gratuito compromesso.
Di norma, gli hacker non monitorano tali punti in tempo reale. Si limitano a raccogliere dati “utili” e ad analizzarli di volta in volta (generalmente in modalità semiautomatica) per decidere come utilizzarli. Possono venderlo ad altre parti interessate o rilevare personalmente determinati account utente.
Come? Semplicemente seguendo il link, possono cambiare la password, accedere all’account e quindi fare quello che vogliono: cambiare l’indirizzo email associato, rubare denaro, eliminare contenuti, ecc.

Soluzione

Per proteggere i vostri utenti da un’esperienza così triste, tutto ciò di cui hai bisogno è limitare il periodo di validità del collegamento, diciamo, a 24 ore.

Il designer aggiunge solo un altro ramo allo scenario e disegna un’altra schermata con il messaggio “collegamento obsoleto”. Lo sviluppatore aggiunge un paio di righe al codice.
Per quanto riguarda gli utenti, quasi nessuno vedrà mai alcuna differenza. La maggior parte di loro utilizzerà il collegamento entro alcuni minuti dalla richiesta di reimpostazione della password. Ma potete star certo che i loro account saranno molto più sicuri ora.

Dati

Un’altra area vulnerabile di cui un designer di prodotti dovrebbe occuparsi sono i dati e il modo in cui vengono inviati, ricevuti e visualizzati all’interno di un prodotto.
Se pensate che lo scambio di dati e tutte le cose correlate siano il parco giochi degli sviluppatori, vi consigliamo di cercare su Google “data design”. Se volete davvero creare prodotti di qualità, facili da usare, scalabili e sicuri, è necessaria almeno una conoscenza di base della progettazione dei dati.
Tuttavia, se eliminate tutti gli aspetti tecnici e le sfumature della progettazione dei dati, arrivi agli stessi dati personali visualizzati all’interno di un prodotto: e-mail, numeri di telefono, carte di credito, ID utente interni, date dell’ultima attività, ecc.

Tutti i dati visualizzati nell’interfaccia utente devono passare attraverso il “può fare del male?” filtro.

Esempio 2

Ogni tanto abbiamo sentito parlare di migliaia di account utente compromessi di servizi noti e meno noti. Molto spesso, la ragione di problemi così seri diventa un minuscolo dato sensibile esposto incautamente al mondo esterno.
Un paio di anni fa, una società fintech ha fatto trapelare oltre 50mila account di utenti. La storia è stata rapidamente messa a tacere, ma un gruppo di appassionati è riuscito a condurre le proprie indagini.
Secondo le loro scoperte, gli utenti del servizio potevano condividere i propri dati con altri utenti tramite collegamenti che portavano a una sorta di biglietti da visita digitali. Tecnicamente, tutto sembrava a posto: gli URL non includevano ID utente, solo lunghi hash personali.
Gli stessi hash (associati a determinati utenti) sono stati utilizzati anche nell’API. Tuttavia, erano ancora inutili se non conoscevi l’ID interno del proprietario dell’hash. Ed è qui che i progettisti del servizio hanno gentilmente aiutato gli hacker: hanno messo l’ID utente interno proprio nell’angolo dei biglietti da visita condivisi. Come mai? Nessuno potrebbe spiegare. Ma questo è bastato per compromettere il servizio.

Soluzione

La soluzione è chiara. Non esporre dati vulnerabili, soprattutto quando non ce n’è assolutamente bisogno.
Se è necessario mostrare un ID, utilizzare invece un insieme casuale di caratteri. Dì solo agli sviluppatori che dovrebbero essere unici per tutte le entità.
Avvolgendo
Attenersi al design funzionale. Vi consente di studiare a fondo tutti gli scenari e i casi limite. Non trascurare la progettazione dei dati poiché i dati non si proteggeranno da soli. Pensaci due volte prima di esporre i dati al mondo esterno.

Circa l’autore:
Pavel Sherer, produttore IT, product designer, analista.