La guida essenziale alla sicurezza dei dati per i product manager
Hai mai sentito parlare di Code Spaces? Era un repository di codice sorgente simile a Github.
Probabilmente però non ne hai mai sentito parlare perché, nonostante fosse un prodotto promettente, è scomparso quasi istantaneamente nel giugno del 2014 dopo una grave violazione della sicurezza. La violazione ha provocato la perdita di tutti i dati dei clienti, costringendoli a cessare l’attività.
Dopo quell’incidente, tutti nel mondo digitale, compresi i product manager, hanno imparato una lezione che non dovrà mai essere dimenticata: I PRODOTTI DEVONO ESSERE SICURI.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
In questa guida, ti introdurrò al mondo della sicurezza dei prodotti e ti aiuterò a mantenere la sicurezza sempre in mente quando gestisci i tuoi prodotti.
Perché i Product Manager dovrebbero preoccuparsi della sicurezza dei dati
In teoria, il tuo quotidiano product management dovrebbe concentrarsi solo sulla retention, sulle interviste agli utenti e su altre attività non tecniche senza preoccuparsi della sicurezza.
Tuttavia viviamo in un mondo dove esistono persone malintenzionate che sarebbero più che felici di rubare i tuoi dati (per poi rivenderli da qualche parte), criptarli, chiedere un riscatto (cioè ransomware) o semplicemente fare danni solo per il gusto di farli.
Quindi, oltre alle metriche di attivazione e retention, dovresti anche interessarti ai rischi di business enormi che una scarsa sicurezza può presentare per il tuo prodotto. Una violazione della sicurezza abbastanza grave può danneggiare la tua reputazione al punto da annullare, in un solo giorno, anni di lavoro del tuo team marketing, sviluppo prodotto e commerciale.
Inoltre, ti troverai a dover affrontare eventuali azioni legali da parte di partner e clienti di cui non hai protetto adeguatamente i dati.
Secondo me, quindi, è di massima importanza che i product manager abbiano sempre consapevolezza della sicurezza quando costruiscono e fanno crescere i propri prodotti.
Le 4 vulnerabilità di sicurezza più comuni nello sviluppo prodotto
Come product manager, non devi per forza conoscere a fondo i metodi di hacking più recenti né come difendersi da questi. Questo compito spetta ai tuoi team di sicurezza e agli ingegneri.
Tuttavia, è importante avere una comprensione tecnica di base di come funzionano alcuni dei problemi di sicurezza più frequenti e di come gli hacker possano sfruttarli. Questo renderà il tuo processo decisionale più attento alla sicurezza.
Vediamo insieme quattro di queste vulnerabilità per capire meglio di cosa si tratta.
1. SQL Injection
Quando ero un giovane PM, decisi di imparare un po’ di programmazione e realizzai un piccolo (e pessimo) codice PHP che serviva come backend per il form di contatto di un sito web. Prendeva un messaggio, lo salvava nel database e componeva un’email indirizzata a me contenente il messaggio stesso.
Quando lo mostrai a un mio amico sviluppatore, che a stento riusciva a non ridere (il mio codice era davvero pessimo), mi chiese se avessi "sanitizzato" gli input. Come avrai già intuito, non ne avevo idea, e lui mi spiegò che senza sanitizzazione i miei database erano esposti a SQL injection.
La SQL injection si verifica quando un hacker inserisce uno speciale codice SQL invece di semplice testo nei tuoi input e riesce a far eseguire quel codice dal backend, ottenendo così accesso non autorizzato al tuo prodotto o rubando informazioni dal database.
Immagina che LinkedIn utilizzasse questa query SQL per verificare la password durante l’accesso (precisazione: adottano sicuramente soluzioni molto più intelligenti di quella presente qui).
Se, in teoria, i campi di accesso non fossero "sanitizzati", potresti inserire ' OR '1'='1 sia nel campo username sia in quello della password e premere Accedi.
In questo caso, il backend aggiungerebbe il tuo ' OR '1'='1 alla query SQL che diventerebbe qualcosa di simile.
Questa query restituirà il valore “true”. Significa che potresti accedere a LinkedIn senza avere effettivamente username e password.
Come già accennato, puoi evitare questo problema "sanitizzando" gli input. Sanitizzazione qui significa fare in modo che ciò che si inserisce nei campi di input venga trattato come semplice testo, anche se si digita codice o query SQL.
Con gli input sanitizzati, LinkedIn tenterà di cercare un utente con nome ' OR '1'='1 nel database invece di eseguire il codice. Non trovando nulla, restituirà un errore dicendo che non esiste nessuna persona con quel nome su LinkedIn.
Proteggersi dalle iniezioni SQL è uno dei passi fondamentali che puoi compiere per mantenere sicuri i dati dei tuoi clienti ed evitare perdite di dati nocive e accessi non autorizzati.
2. Cross-Site Scripting (XSS)
XSS è un altro metodo comune che gli hacker utilizzano per manipolare il tuo prodotto e compiere azioni dannose su di esso. Per capire quanto sia diffuso l’XSS, un rapporto di Positive Technologies stima che circa il 90% di tutte le applicazioni web sia vulnerabile a questo genere di attacco.
Ma di cosa si tratta? L’XSS è simile all’iniezione SQL perché prevede che l’hacker manipoli il tuo sistema per eseguire codice che non avrebbe dovuto girare. Tuttavia, in questo caso il codice malevolo non viene eseguito nel backend/database del sistema, ma nel frontend.
Uno degli esempi più curiosi e innocui di XSS è stato l’emoji del cuore auto-retwittato su Twitter (sì, io lo chiamo ancora Twitter — provate a contraddirmi). Fa ridere perché nessuno si aspettava una gaffe così grande da Twitter, ed è innocuo perché tutto ciò che faceva era retwittare se stesso.
Questo attacco consisteva semplicemente in un tweet contenente il testo seguente.
Come si nota dall’immagine, non si tratta di semplice testo, ma di un pezzo di codice (Javascript con jQuery, per la precisione) insieme a un’emoji a forma di cuore alla fine.
Prima che Twitter correggesse questa falla di sicurezza, se aprivi quel tweet nel browser, il motore del browser lo interpretava come codice valido, lo nascondeva all’utente e lo eseguiva. Quindi, invece delle due righe di codice, vedevi solo un tweet con un’emoji a forma di cuore.
All’avvio del codice, questo navigava attraverso l’HTML della pagina, trovava automaticamente il tasto retweet sullo schermo e ci cliccava sopra.
Significava che chiunque aprisse quel tweet lo retwittava automaticamente, provocando "l’infezione" di un’enorme fetta di utenti Twitter.
Ora, immagina se non si fosse trattato di un tweet che si autoriproduceva, ma di qualcosa di più pericoloso, come uno script in grado di estrarre informazioni riservate dallo schermo e inviarle a un hacker. Oppure un codice malevolo, in esecuzione sul browser, potrebbe prendere il controllo dell’app web di home banking e iniziare a trasferire fondi dal tuo conto.
Hai capito il punto—XSS è ancora molto pericoloso pur non potendo accedere ai tuoi server e database.
Ma perché dovrebbe importarti come product manager? Potresti finire per chiedere ai tuoi ingegneri di implementare funzionalità e integrazioni interessanti, come consentire al tuo sito di visualizzare il contenuto di altre schede aperte nel browser dell’utente e di farci qualcosa di utile.
Se lo chiedi e il tuo team si rifiuta di realizzare questa funzione, non restarci male o confuso: ciò che stai chiedendo equivale di fatto a un attacco XSS su altri siti.
L’XSS è un ambito affascinante nella cybersecurity e ci sono tanti ottimi libri che potrei consigliare. Il mio preferito è XSS Attacks di Seth Fogie.
3. API non sicure
Le Application Programming Interface (note anche come API) sono il mezzo di comunicazione tra il tuo server e il browser dell’utente o la tua applicazione sul suo dispositivo mobile/desktop.
Ogni volta che occorre ottenere, memorizzare o elaborare dati sul tuo server, il browser/app (cioè il “client”) invierà una richiesta al server con le informazioni necessarie. Poi, il server elaborerà la richiesta e produrrà la risposta.
Ad esempio, durante il login, i client inviano username e password e chiedono al server di autenticare l’utente. Non appena il server completa la richiesta, invia un messaggio di “successo” insieme al contenuto della pagina che l’utente deve vedere dopo il login.
Poiché le API trattano dati degli utenti, sono anch’esse vulnerabili a problemi di sicurezza che possono portare a manipolazioni malevole dei dati (ad es. chiedere al server di effettuare un bonifico a nome dell’utente) o a una violazione dei dati (ad es. chiedere al server di mostrare le cartelle cliniche di un utente).
I tipi di vulnerabilità delle API più comuni sono:
Nessuna autenticazione: In questo caso l’API non richiede al client di provare la propria identità prima di fornire dati riservati. Per rendere l’idea, immagina qualcuno che si reca in banca e chiede di prelevare soldi dal conto di Mark Zuckerberk, e il cassiere risponde semplicemente: "Certo, quanto?"
Nessun limite di richieste: In questo caso, le API non smettono di processare le richieste, anche se ce ne sono troppe—cioè, molte di più di quante dovrebbero essere—portando a un sovraccarico del server e al suo crash. Questo tipo di flusso eccessivo di richieste si verifica quando qualcuno prova a effettuare un attacco DDoS sui tuoi server.
Esposizione eccessiva dei dati: Questo si verifica quando le risposte delle tue API contengono informazioni a cui non vuoi davvero che le persone accedano. Ad esempio, quando invii denaro a qualcuno tramite l’home banking, supponiamo che la notifica API che conferma il successo dell’operazione contenga anche il saldo del conto del destinatario, cosa che sicuramente non dovresti vedere.
Le soluzioni a queste tre vulnerabilità sono piuttosto ovvie. Chiedi l'autenticazione quando servi dati sensibili, aggiungi un limite alle richieste e verifica di non restituire dati che non dovrebbero essere inclusi.
Se vuoi approfondire l’argomento della sicurezza delle API, puoi consultare il libro di Neil Madden in merito.
4. Mancanza di Crittografia
Il mio responsabile della sicurezza ama ripetere continuamente che una strategia di cybersicurezza ben fatta su un prodotto somiglia a una cipolla: è composta da diversi strati di sicurezza distribuiti sulle varie parti del prodotto.
Tutto ciò di cui abbiamo parlato finora riguarda rischi di sicurezza degli strati superficiali, quando l’utente non può accedere ai tuoi server o database e prova ad attaccare “dalla superficie”.
Tuttavia, se un hacker dovesse riuscire ad avere pieno accesso ai tuoi server (penetrando il primo strato), dovresti avere comunque delle misure in atto per proteggere i tuoi database da accessi non autorizzati, mantenendo sicuri anche gli strati interni.
Uno dei modi migliori per proteggere i tuoi dati, in questo caso, è criptarli. Significa che, anche se qualcuno accede ai tuoi database e scarica quei dati, per loro saranno solo delle informazioni incomprensibili poiché sono crittografate.
Solo l’azienda o l’utente—le uniche due parti che possiedono la chiave di crittografia—saranno in grado di decriptare quelle informazioni senza senso e trasformarle in dati utili. Sfortunatamente, però, dimenticare di criptare i dati sui server è molto comune e ha portato a numerose, enormi fughe di dati.
Personalmente, ho visto fin troppi siti e prodotti che hanno rischiato memorizzando le password dei propri utenti in chiaro—cosa che viene considerata un vero peccato capitale nello sviluppo software. La miglior prassi in questi casi è far passare la password attraverso un algoritmo di hashing, ottenere una versione crittografata di essa (detta hash) e memorizzare quella al suo posto.
La bellezza di tutto ciò è che sia l’utente che l’azienda hanno la chiave per riportare l’hash alla sua forma testuale originale e usare quella password per autenticazione. Ma, se un hacker accede al DB e scarica l’hash, tornare alla password originale richiederebbe milioni di anni di calcoli senza la chiave. (Non sto scherzando, questo è il numero reale!)
La crittografia è un’altra area affascinante della cybersicurezza che ti consiglio di approfondire. In particolare, puoi iniziare imparando come funziona la crittografia a chiave pubblica, perché è su questo principio che oggi funziona tutto Internet.
Integrare la Sicurezza Applicativa nel Ciclo di Vita dello Sviluppo di Prodotto e Software
Avendo in mente tutte queste vulnerabilità e buone pratiche, concentriamoci su una domanda ovvia che potresti avere—come faccio a mantenere sicuri i miei prodotti come PM?
Non vedevo l’ora che lo chiedessi! Ecco due importanti buone pratiche di sicurezza che possono aiutarti:
Prodotti Sicuri per Progettazione
Questo è un approccio al processo di sviluppo che prevede di tenere presenti i requisiti di sicurezza fin dal primo momento in cui inizi a costruire i tuoi prodotti, in modo che le misure di sicurezza siano integrate nativamente nel codice e nell’architettura, invece di essere aggiunte successivamente nel SDLC.
Questo secondo approccio di solito è molto più costoso e non assicura lo stesso livello di protezione rispetto a un software “nativamente” sicuro.
Quindi, come product manager, è tua responsabilità chiedere al tuo team di sviluppo di seguire questo approccio e di non dare meno importanza agli elementi che aiutano a costruire la sicurezza nel prodotto.
More Articles
- L’IA nella Ricerca sugli Utenti: Come l’Intelligenza Artificiale Sta Trasformando le Analisi sugli Utenti
- Spedire Prodotti Global-First Senza il Mal di Testa Globale: Come Integrare la Localizzazione nel Tuo Flusso di Lavoro di Prodotto
- L’IA nella Pianificazione dello Sprint: Come l’IA Migliora l’Efficienza del Team
Audit di Sicurezza Regolari
La maggior parte dei prodotti che ho gestito viene sottoposta a test di sicurezza regolari (di solito una volta ogni sei mesi o un anno). Verificavamo l’intera postura di sicurezza, che includeva:
- Test di penetrazione
- Modellazione delle minacce
- Revisione dei controlli di sicurezza
- Revisione della strategia di sicurezza e delle funzionalità di sicurezza
- Revisione della catena di fornitura e dei flussi di lavoro automatizzati
- Analisi del codice (incluso il codice open source che abbiamo utilizzato e quello ottenuto da partenariati con terze parti)
- Creazione della roadmap di sicurezza e delle metriche
- Valutazione del rischio
- ...e molto altro!
Questo è importante perché il tuo prodotto è in costante evoluzione e potresti accidentalmente compromettere la sicurezza del software mentre aggiungi nuove funzionalità. Gli audit regolari permettono di individuare rapidamente questi problemi, consentendoti di risolverli e convalidarli—prima che lo faccia un malintenzionato.
Come product manager, il tuo compito è allocare tempo e dare priorità a questi audit e alle successive pulizie del codice.
Fidati del tuo team di sicurezza
Indipendentemente dalla funzionalità che intendi sviluppare e dai piani d’azione previsti per raggiungere i tuoi obiettivi di crescita, assicurati sempre di confrontare le tue idee con il team di sicurezza.
Ascolta: potrebbe sembrarti che le persone della sicurezza vogliano "ipertutelare" il tuo prodotto. Tuttavia, nella maggior parte dei casi, se non approvano una tua idea, dovresti davvero valutare di modificarla. Altrimenti il rischio non ne vale la pena.
E già che ci sei, prendi in considerazione anche di iscriverti alla nostra newsletter per ricevere tante guide e articoli di product management direttamente nella tua casella di posta!
