Vuoi che la tua sicurezza sia costruita su scuse?

14/07/21 CoreTech Blog

Opinione: Lasci le chiavi della macchina nel quadro solo perché è più facile che mettere in sicurezza il tuo veicolo? In caso contrario, perché ti vengono in mente scuse simili quando prendi decisioni sulla sicurezza dei tuoi dati sensibili e sulla reputazione della tua azienda?

Nel mondo della sicurezza informatica, è naturale bilanciare rischi e misure di sicurezza. Dopotutto, non c'è modo di ottenere una sicurezza assoluta e quindi devi dire fermati da qualche parte. Tuttavia, se ti affidi alle scuse e sottovaluti le minacce, è molto probabile che tu diventi vittima di un attacco serio. I criminali informatici sono intelligenti: attaccano coloro che rendono loro le cose facili.

Ho visto le aziende trattare la sicurezza delle applicazioni web come meno importante, ad esempio, di avere un antivirus. Posso capire un tale approccio se un'azienda ha solo un semplice sito di marketing su WordPress. Tuttavia, non riesco a capire una tale disattenzione se l'azienda sviluppa applicazioni Web B2B professionali per grandi aziende, che utilizzano queste applicazioni Web per elaborare tonnellate di informazioni sensibili! Eppure, sì, succede!

Ecco alcune delle scuse che ho sentito quando si tratta di sicurezza delle applicazioni web. Li sto includendo per aiutarti a evitare insidie ​​simili quando decidi come procedere con il tuo viaggio.

"Il nostro software è solo per uso interno, quindi non c'è rischio di attacco"

Il presupposto che gli hacker malintenzionati attacchino solo le applicazioni web che sono esposte al pubblico è uno dei motivi principali delle principali violazioni dei dati. Non solo i lavori interni sono abbastanza comuni nel mondo della sicurezza informatica, ma gli aggressori possono trovare un modo per entrare nella rete interna e accedere da lì alle applicazioni web interne.

Dovresti sempre trattare la sicurezza delle tue applicazioni web allo stesso modo, indipendentemente dal fatto che siano esposte al pubblico, utilizzate solo tramite reti interne e VPN o protette da filtro IP e autenticazione. Ciò significa che, ad esempio, se la tua applicazione è accessibile solo da un intervallo selezionato di IP e richiede l'autenticazione, non significa che sia sicura in base alla progettazione. Ancora peggio, i criminali possono effettivamente cercare di accedere a tali applicazioni, in particolare, sapendo che i loro creatori spesso trattano le vulnerabilità come una minaccia minore e quindi non le controllano nemmeno.

In conclusione, scansiona ogni applicazione alla ricerca di vulnerabilità di sicurezza, non importa quanto bene sia protetta dalle misure di sicurezza e dall'autenticazione della rete!

“La nostra implementazione rende impossibile avere vulnerabilità”

Ho sentito questo argomento da un'azienda, che utilizza Hibernate ORM per il suo sviluppo Java. La costruzione di Hibernate elimina presumibilmente le vulnerabilità di SQL injection perché il database restituisce sempre un singolo set di risultati. Sfortunatamente, non è vero. Solo alcuni attacchi SQL injection vengono eliminati da questa funzionalità di Hibernate, ma non tutti. Questa funzionalità inoltre non ha alcun impatto sulle vulnerabilità che non sono correlate a SQL.

Sebbene i moderni ambienti di sviluppo e implementazione rendano più difficili alcuni attacchi, non esiste un ambiente che possa aiutarti a prevenirli tutti o anche la maggior parte di essi. Se pensi che il modo in cui hai progettato lo sviluppo e l'implementazione sia sufficiente senza alcun test di sicurezza incluso, ripensaci.

In conclusione, testa tutte le tue applicazioni per le vulnerabilità della sicurezza, indipendentemente dagli ambienti di sviluppo e implementazione che utilizzi (anche se presumibilmente eliminano gli errori di sicurezza).

"Eseguiamo una scansione di sicurezza di tanto in tanto e non abbiamo mai trovato nulla di serio"

Alcune aziende ritengono che sia sufficiente eseguire la scansione delle proprie applicazioni ogni pochi mesi, ad esempio solo prima di una versione principale. Non vedono la necessità di verificare la sicurezza di ogni release candidate e sono ancora meno desiderosi di includere la scansione della sicurezza come parte delle loro normali pipeline DevOps. L'argomento è che le scansioni non hanno prodotto grossi problemi fino ad oggi.

Un simile approccio può essere paragonato a lasciare la portiera dell'auto aperta (e le chiavi nell'accensione) di fronte al supermercato. Certo, nella maggior parte dei casi non succederà nulla perché non ci saranno ladri d'auto in giro. Tuttavia, se solo un ladro è in giro e nota che la tua auto non è chiusa a chiave, il tuo veicolo cambierà proprietario abbastanza rapidamente. Lo stesso in questo caso: solo una vulnerabilità importante che non viene rilevata tra le versioni principali può comportare una violazione della sicurezza che espone tutti i tuoi dati sensibili e rovina la reputazione della tua azienda.

In conclusione, testate le vostre applicazioni presumibilmente sicure in modo ancora più approfondito di quelle che pensereste non sicure.

Meglio prevenire che curare

La frase "meglio prevenire che curare" è molto applicabile alla sicurezza informatica (e alla sicurezza in generale). A mio parere, qualunque decisione tu prenda in materia di sicurezza per la tua attività, dovresti confrontarla con la sicurezza delle tue risorse personali. Ad esempio, se il tuo appartamento si trova in un condominio con la sicurezza alla porta d'ingresso, significa che puoi lasciare la porta aperta? Se di recente non si è verificata alcuna intrusione nel tuo quartiere, significa che puoi lasciare la finestra spalancata quando vai al lavoro?

Se invece di cercare scuse provi a ipotizzare gli scenari peggiori, è molto meno probabile che tu sia l'eroe della prossima notizia principale su una violazione dei dati.