Ciao a tutti.
Oggi, invece di parlare di hacking e irruzione nei sistemi come facciamo di solito,
parleremo di sicurezza e in particolare di come proteggere siti web, applicazioni web, applicazioni mobili e così
via.
Ovviamente, hack e violazioni hanno un enorme impatto negativo sulle aziende, dalla perdita di fiducia dei
clienti alle perdite finanziarie.
Dati utente trapelati, problemi legali e l'elenco potrebbe continuare.
Ora, se fai una rapida ricerca su Google su come proteggere il tuo sito web o la tua applicazione,
otterrai un sacco di spazzatura.
In realtà ero così deluso dagli articoli clickbait che in realtà non spiegavano o fornivano alcuna informazione
utile.
La maggior parte di loro ha suggerito di utilizzare backup, password complesse e assicurarsi di utilizzare HTTPS.
Ma i backup non proteggono il tuo sito web, ti aiutano semplicemente a recuperare.
Inoltre, l'utilizzo di ETP crittografa la comunicazione, ma non protegge realmente il sito web.
L'unico consiglio utile era usare password complesse.
Ma la maggior parte degli hacker non si siederà e cercherà di indovinare la password come si vede nei film di Hollywood.
Faranno affidamento sulle vulnerabilità e sui punti deboli della tua applicazione e le
sfrutteranno per accedervi, indipendentemente dalla password che utilizzi.
Anche se hai una password molto, molto complessa, anche se stai usando HTTPS e anche se hai dei backup, molto di
questo è in realtà irrilevante.
Inoltre, non importa dove hai ospitato l'applicazione, se usi un A. W. o qualsiasi altro provider
cloud e non importa come stai distribuendo questa applicazione.
Se stai usando Kubernetes o se stai usando Docker, non importa.
In realtà è molto, molto semplice.
Se disponi di un'applicazione Web vulnerabile, gli hacker utilizzeranno queste vulnerabilità o punti deboli
per accedere a questa applicazione.
Quindi, comunque, basta sbraitare.
Parliamo di come proteggere effettivamente siti Web e applicazioni.
Prima di tutto, prima di iniziare a parlarne, è molto importante capire che raggiungere
il 100% di sicurezza è impossibile.
Tutto ciò che stiamo cercando di fare è migliorare la sicurezza delle nostre applicazioni e assicurarci che siano il
più sicure possibile.
Detto questo, i seguenti quattro approcci ti aiuteranno a migliorare la sicurezza delle tue applicazioni, indipendentemente dal
tipo di applicazioni che sono e indipendentemente da dove sono installate.
Come ho detto, non importa se li installi su Amazon o altrove su un WIC o qualsiasi altra
cosa, e non importa come lo stai distribuendo se stai usando Docker e così via.
Quindi la prima cosa che dovresti fare è assicurarti di scrivere codice sicuro in questo modo.
La tua applicazione è costruita da zero per essere sicura e per non introdurre bug o vulnerabilità che
possono essere sfruttate dagli hacker per ottenere l'accesso.
Ora, sarebbe fantastico se riuscissi a farlo, ma il problema è che è più facile a dirsi che a
farsi perché gli sviluppatori hanno bisogno di essere istruiti e insegnati i metodi usati dagli hacker per sfruttare i sistemi e ottenere
l'accesso.
E anche se lo fai, molto spesso gli sviluppatori si affidano a librerie di terze parti e l'intera applicazione potrebbe
essere scritta da qualcun altro.
Pertanto, semplicemente non puoi scrivere codice sicuro perché in realtà non sei lo scrittore o lo sviluppatore
di questa applicazione.
Il che mi porta al secondo punto.
Revisione del codice.
Questo è davvero molto buono, anche se hai scritto tu stesso l'applicazione, e anche se ti sei assicurato
di scrivere codice sicuro, è davvero una buona idea far revisionare quel codice da altri sviluppatori o da un
altro team.
Nel caso in cui gli sviluppatori abbiano scritto che l'applicazione si sia persa qualcosa o abbia trascurato qualcosa,
verrà rilevata nella fase di revisione.
Inoltre, se stai utilizzando il codice scritto da altri sviluppatori o librerie di terze parti, una revisione del
codice risolverà questo problema perché puoi rivedere e tutto il resto.
E ancora, questo è davvero, davvero buono perché stai effettivamente rivedendo ogni singola riga
e assicurandoti che nulla sia vulnerabile o consentirà agli hacker di sfruttare la tua applicazione e ottenere l'accesso.
Lo svantaggio principale qui è che se si dispone di una grande base di codice, ciò potrebbe richiedere
molto tempo e potrebbe anche essere molto costoso.
Il terzo approccio, che è molto essenziale, secondo me, è fare un test della penna.
In un test di penna.
Fondamentalmente assumi un team di hacker etici per provare a hackerare la tua applicazione.
Questi hacker etici si avvicineranno alla tua applicazione allo stesso modo degli hacker Black Hat.
Cercheranno di raccogliere quante più informazioni possibili e scoprire tutte le debolezze e le vulnerabilità e
vedere se possono sfruttarle per ottenere l'accesso.
Alla fine, quando avranno finito, ti daranno un rapporto dettagliato di tutto ciò che hanno trovato
in modo che tu possa passarlo ai tuoi sviluppatori e correggere eventuali vulnerabilità che scoprono.
Il vantaggio principale di questo metodo è che puoi testare superfici di attacco che non puoi testare con
altri metodi, come i tuoi server che eseguono la tua applicazione web e l'anello più debole, ovvero
i dipendenti.
Quindi questi hacker, gli hacker etici, possono persino utilizzare l'ingegneria sociale e concatenarla con altri attacchi più semplici
o vulnerabilità più semplici che potrebbero trovare sul tuo sistema per vedere se possono usarli per
ottenere l'accesso.
Gli svantaggi qui sono che potrebbe essere un po' costoso e non è a prova di futuro.
Quello che voglio dire è che se fai testare la tua applicazione oggi da un hacker etico davvero bravo
e poi assicurati di correggere ogni singola vulnerabilità che trovano, questo significa solo che la tua applicazione web è sicura
oggi.
Non garantisce che rimarrà sicuro per il prossimo mese o l'anno prossimo, perché ogni singola
modifica apportata, ogni funzionalità inserita o anche ogni bug di visualizzazione corretto potrebbe introdurre altri bug o
punti deboli di sicurezza che possono essere utilizzati per hackerare la tua applicazione.
Non solo, ma anche in questo caso, se stai aggiornando di nuovo software o plug-in di terze
parti, tutto ciò potrebbe introdurre vulnerabilità e un test non sarà in grado di rilevarlo perché stai solo facendo
i Panthers oggi e questi cambiamenti futuri sono non sarà testato.
Il quarto approccio, che può effettivamente affrontare questo problema, è avere un programma di ricompensa dei bug.
Un programma bug bounty è fondamentalmente un invito a tutti gli hacker etici di tutto il mondo per testare la
tua applicazione e inviare i loro risultati.
E pagheresti solo per bug validi o segnalazioni valide.
Il vantaggio principale è qui, come avrai intuito, probabilmente ormai, è che stai facendo testare
la tua applicazione da un gran numero di hacker, quindi le probabilità che trovino vulnerabilità sono maggiori.
Ed è in realtà a prova di futuro perché finché hai quell'elenco di taglie di bug attivo, questi hacker continueranno sempre
a testare la tua applicazione e tu li motiverai con le taglie.
Quindi questo potrebbe essere qualsiasi cosa, da una maglietta a premi in denaro.
Per assicurarti che continueranno a testare la tua applicazione.
Quindi, anche se stai spingendo nuove modifiche, nuove funzionalità o aggiornando cose, non importa perché
gli hacker continueranno a testare la tua applicazione sperando di trovare bug e ottenere premi per le loro scoperte.
Ecco perché le grandi aziende come Facebook e Google utilizzano questi programmi di bug bounty, anche se seguono
tutti gli altri approcci.
Come ho detto, lo usano ancora per assicurarsi che i loro sistemi siano sempre il più sicuri possibile e il
più possibile privi di bug.
Gli svantaggi qui sono, prima di tutto, che è difficile garantire che tutte le superfici di attacco siano coperte.
E in secondo luogo, molte aziende non hanno la portata di Google e Facebook, quindi non possono davvero
pubblicizzare i loro premi di bug come fanno le grandi aziende.
Non possono convincere molti hacker etici a testare il loro sito web.
È difficile per loro creare questi programmi di ricompensa dei bug e convalidare i rapporti inviati.
Ma questo è affrontato dalle piattaforme di bug bounty che abbiamo in questi giorni, come bug bounty, dotcom
e le altre piattaforme.
Bug Bounty è in realtà una consociata di quella sicurezza.
Quindi la mia opinione potrebbe essere un po' di parte, ma sono abbastanza sicuro che i nostri prezzi siano i più competitivi
e offriamo lo stesso servizio.
Comunque, io sono incluso in tutto quello che c'è.
Hai la scelta.
Puoi controllare quello che vuoi, e mi dispiace se ti ho davvero confuso con l'approccio autunnale.
È quello che ho appena menzionato, ma secondo me, idealmente, dovresti seguire tutti e quattro questi
approcci, se puoi.
Questo potrebbe essere piuttosto costoso.
Ecco perché molte aziende non lo fanno.
E avrebbero fatto un compromesso e sarebbero andati solo con tre e quattro.
Quindi faranno solo un patch test e avranno un programma di bug bounty.
E poi altre aziende a volte compromettono ancora di più.
E scegli uno dei due o fai un programma di ricompensa dei bug o fai un test della penna.
A mio parere, un test della penna non è un sostituto di un programma di bug bounty e viceversa.
Ti consiglierei di fare i due perché, come ho detto, ognuno di loro ha i suoi
vantaggi e svantaggi.
Ma se davvero non puoi fare entrambe le cose, allora almeno fallo come minimo indispensabile.
In qualità di proprietario di un sito Web o di un'app, sei responsabile dei dati utente di cui gli utenti
si fidano e quindi devi fare almeno il minimo indispensabile per assicurarti che i loro dati
siano gestiti in modo sicuro e protetto.