Become a partner   | Request Support  | Contact Sales

Diventa Autore per CoreTech | Scopri di più





Quattro modi per combattere il divario di competenze di sicurezza informatica

29/06/22 CoreTech Blog

La mancanza di talento per la sicurezza informatica non è una novità. È un problema che tutte le aziende devono affrontare da diversi anni e sta peggiorando. Ci sono state molte proposte su come ridurre il divario, ma finora tutti gli sforzi sono stati inutili. Diamo un'occhiata a cosa sta causando il divario, cosa si può fare per ridurlo e quali riteniamo siano i modi migliori per combattere efficacemente la carenza di competenze di sicurezza informatica.

Passaggio 1. Accetta la carenza di competenze di sicurezza informatica

Le analisi di settore hanno previsto che nei prossimi anni il divario aumenterà ancora, come è già stato da prima della pandemia. Mentre alcune strategie di riduzione del divario potrebbero rivelarsi efficaci a lungo termine, non sembra che si possa fare nulla a breve termine.

Ci sono diversi motivi per cui il divario si sta allargando:

  • Sebbene le tecnologie IT siano già la spina dorsale di un'azienda, sono ancora in fase di sviluppo e crescita. Sempre più organizzazioni di tutte le dimensioni stanno adottando l'IT per sempre più scopi con le tecnologie cloud che lo rendono molto più semplice. Pertanto, il numero di risorse da proteggere continua a crescere rapidamente, così come il numero di offerte di lavoro nella sicurezza informatica, in particolare nel campo della sicurezza del cloud e della sicurezza delle applicazioni web.
  • I criminali stanno trovando nuovi modi per sfruttare la mancanza di sicurezza IT e stanno imparando come trarne vantaggio. Alcuni anni fa, la criminalità informatica era percepita principalmente come il fulcro di piccole operazioni, ma è sempre più adottata dalle principali organizzazioni criminali. Ciò significa che il rischio di un attacco informatico è maggiore, soprattutto per le grandi imprese e istituzioni.
  • Quando le aziende crescono, cresce anche la complessità dei loro sistemi. Ciò significa che non solo ci sono più risorse da proteggere, ma sono anche più difficili da proteggere.
  • Il lavoro è spesso molto stressante per i professionisti della sicurezza informatica. I ruoli di sicurezza informatica comportano grandi responsabilità e molta incertezza perché non puoi mai proteggere i sistemi da ogni possibile tipo di intrusione. Quando si verifica una violazione, di solito vengono incolpati i professionisti della sicurezza, non coloro che sono responsabili della causa principale del problema. Gran parte della carenza di talenti è causata dal burnout dei professionisti esistenti.
  • Per la natura del proprio lavoro, chi opera nel campo della cybersecurity spesso preferisce lavorare come freelance nel settore privato invece di entrare a far parte di grandi organizzazioni, soprattutto nell'era post-COVID, quando il lavoro a distanza e freelance è ancora più comune. D'altra parte, le grandi organizzazioni non si sentono sempre a proprio agio nell'affidare a qualcuno che non fa parte della loro cultura qualcosa di così importante come la sicurezza.
  • La sicurezza informatica è difficile da imparare, quindi il pool di talenti è limitato. Non solo richiede un'eccellente comprensione dell'IT e un ampio set di competenze tra cui sviluppo e amministrazione, ma anche una mente curiosa e creativa con talenti diversi e la capacità di pensare fuori dagli schemi. Non ci sono molte persone al mondo che possono gestirlo.
  • La sicurezza informatica non è stata ancora adottata da un numero sufficiente di istituzioni educative. Ci sono solo pochi programmi di sicurezza informatica di quattro anni, sia in Nord America che altrove, la preparazione per le carriere di sicurezza informatica e l'educazione alla sicurezza informatica spesso inizia troppo tardi, mentre potrebbe già iniziare anche nelle scuole superiori: una formazione/certificato ISC sul lavoro non è abbastanza per diventare un esperto di sicurezza informatica. Peggio ancora, il divario di talenti nella sicurezza informatica colpisce anche le istituzioni educative perché non ci sono abbastanza esperti disposti a insegnare agli altri.

Passaggio 2. Migliorare la consapevolezza ed educare

Alcune aziende tentano di ridurre il divario riqualificando i propri professionisti IT. Sebbene sia possibile che alcuni dipendenti con competenze tecniche siano in grado e disposti ad assumere posizioni di sicurezza informatica, devono comunque avere qualcuno che li insegni. La maggior parte degli esperti di sicurezza informatica oggi sono autodidatti e c'è ben poco che un'organizzazione può fare per aiutare perché anche la disponibilità delle certificazioni di sicurezza è limitata.

Banner

Tuttavia, il vero problema è che le organizzazioni spesso percepiscono la sicurezza informatica come qualcosa che solo la forza lavoro dedicata alla sicurezza informatica dovrebbe affrontare. Questa percezione è la causa di diversi problemi sopra menzionati, ad esempio l'alto livello di stress e burnout per il personale di sicurezza informatica. I team di sicurezza spesso lavorano da soli e il resto dell'organizzazione non è consapevole, non è istruito e, peggio di tutto: non si sente responsabile della sicurezza.

Pertanto, la chiave per ridurre il divario è considerare la sicurezza informatica come un problema per tutti. Sviluppatori, amministratori, DevOps, ingegneri QA e persino il personale non tecnico dovrebbero essere informati e istruiti.

  • Le organizzazioni dovrebbero introdurre una formazione di base sulla sicurezza informatica per tutti i membri dell'azienda, ad esempio per combattere malware, phishing/ingegneria sociale e attacchi ransomware. Dovresti rendere tale formazione parte di un normale programma di lavoro, non solo trattarla come un'attività di inserimento una tantum o un'iniziativa occasionale.
  • Il tuo team di sicurezza informatica dovrebbe includere più educatori. Quando cerchi nuovi talenti, assicurati che i candidati siano in grado e disposti a fornire formazione.
  • Ogni sviluppatore dovrebbe avere una formazione di base su come evitare le vulnerabilità della sicurezza nel codice ed essere ritenuto responsabile di tali problemi tanto quanto qualsiasi altro bug.
  • Ogni ingegnere del controllo qualità dovrebbe sapere come utilizzare gli strumenti per verificare la sicurezza informatica. Strumenti come gli scanner di vulnerabilità non dovrebbero più essere nelle mani di un dipartimento di sicurezza separato ma trattati allo stesso modo, ad esempio, di Selenium.
  • Ogni ingegnere DevOps dovrebbe conoscere gli strumenti di sicurezza che possono essere utilizzati con i sistemi CI/CD, come gli scanner DAST e SAST, sapere come configurarli e includerli in tutte le pipeline.
  • Ogni project manager, ogni proprietario di prodotti o servizi e ogni team leader dovrebbe trattare i problemi di sicurezza informatica nello stesso modo in cui vengono trattati gli altri bug e dare priorità alla loro correzione negli sprint.
  • L'organizzazione deve rendersi conto che prima inizi a occuparti della sicurezza assegnando i budget giusti alle iniziative preventive, meno è probabile che dovrai spendere molto di più per la risposta agli incidenti.
  • Infine, ogni dirigente dovrebbe essere consapevole dell'importanza della sicurezza delle informazioni e della sicurezza informatica in generale, non solo del CISO. I dirigenti dovrebbero anche comprendere il panorama delle minacce, ad esempio, dovrebbero rendersi conto che le minacce interne sono importanti quanto le minacce informatiche esterne e le risorse aziendali interne e i sistemi informativi richiedono la stessa protezione di quelli pubblici.

Passaggio 3. Abbraccia gli estranei

I più grandi leader IT del mondo stanno dando un esempio che dovrebbe essere seguito da ogni organizzazione. Aziende come Google, Facebook, Apple e Microsoft hanno tutte programmi di ricompensa per i bug di sicurezza. Se possono fidarsi degli estranei con i loro sistemi, puoi farlo anche tu.

I programmi di ricompensa dei bug hanno diversi vantaggi:

  • È possibile ridurre la necessità di test di sicurezza interni. Gli hacker white-hat freelance eseguiranno volentieri test di penetrazione dei tuoi sistemi solo per ottenere la taglia.
  • Puoi migliorare il modo in cui la tua azienda viene percepita nella comunità IT. Se sei abbastanza audace da offrire una taglia per aver trovato un bug, significa che la tua azienda ha fiducia nella sua posizione di sicurezza.
  • Se i giovani liberi pensatori indipendenti hanno un modo per fare soldi in modo efficace con le proprie capacità senza compromettere la loro preferenza per l'indipendenza, un minor numero di giovani di questo tipo passerà al lato oscuro e diventerà criminale informatico. Pertanto, i programmi di ricompensa sottraggono efficacemente risorse che altrimenti potrebbero rafforzare le organizzazioni criminali.

Tuttavia, devi ricordare che avere un programma bug bounty da solo non è sufficiente. Devi rivelare responsabilmente le vulnerabilità e devi dare la priorità alla risoluzione dei problemi di sicurezza relativi alle taglie. In caso contrario, gli hacker white-hat spesso rilasceranno pubblicamente i dettagli della tua vulnerabilità solo per darti una spiacevole spinta nella giusta direzione.

Molte violazioni dei dati negli ultimi anni avrebbero potuto essere evitate dalle principali organizzazioni se solo quelle organizzazioni avessero avuto un programma di ricompense e avessero collaborato con gli hacker invece di temerli. Sfortunatamente, molte aziende pensano ancora che se un hacker li contatta per una vulnerabilità che hanno scoperto, quell'hacker è un "cattivo ragazzo" che dovrebbe essere segnalato alle autorità e la loro richiesta di taglia è una "richiesta di riscatto". Con una tale mentalità, molti hacker diventano criminali informatici anche se le loro intenzioni erano buone.

Passaggio 4. Promuovi l'automazione e l'integrazione

Il settore della sicurezza informatica è ancora un po' indietro rispetto alle tendenze e molti strumenti vengono ancora creati pensando a specialisti della sicurezza dedicati. Tali strumenti sono difficili o addirittura impossibili da utilizzare in ambienti complessi, ad esempio come parte di un ambiente DevSecOps (o SecDevOps ). Questo può essere un grave problema per le organizzazioni che cercano di utilizzare i metodi sopra menzionati per ridurre l'impatto dei lavori di sicurezza informatica non occupati.

Una soluzione di sicurezza informatica, indipendentemente dal fatto che si tratti di sicurezza web o sicurezza di rete, non dovrebbe più essere uno strumento per un team dedicato. Il loro utente principale non dovrebbe essere l'analista della sicurezza. Uno strumento moderno dovrebbe essere progettato come segue:

  • Gli sviluppatori non dovrebbero essere costretti a utilizzare uno strumento dedicato. Ad esempio, se devono correggere un bug relativo alla sicurezza, dovrebbero utilizzare il loro normale sistema di gestione dei problemi proprio come fanno con qualsiasi altro bug. Pertanto, la soluzione di sicurezza informatica dovrebbe essere completamente integrata con un tale sistema di gestione dei problemi e non richiedere allo sviluppatore di accedere a uno strumento diverso per gestire il problema.
  • Gli ingegneri QA non dovrebbero essere costretti a eseguire test di sicurezza manuali utilizzando strumenti dedicati. Dovrebbero includere test di sicurezza nelle loro suite regolari eseguiti automaticamente come parte dell'SDLC.
  • Gli ingegneri DevOps dovrebbero essere in grado di integrare facilmente i test di sicurezza nelle pipeline CI/CD, proprio come fanno con qualsiasi altro tipo di test. Non dovrebbero dedicare troppo tempo alla configurazione dello strumento di sicurezza.

Uno strumento di sicurezza moderno per l'azienda dovrebbe essere invisibile alla maggior parte degli utenti. Puoi ottenerlo solo se lo strumento è progettato per essere automatizzato e integrato il più possibile anche negli ambienti più complessi. E costruire uno strumento del genere è esattamente ciò che Invicti / Acunetix stanno facendo per avere i nostri "cinque centesimi" nel colmare il divario.

Banner


Articoli su Sicurezza

Sicurezza aziendale: da cosa è minacciata e come proteggerla?Il threat modeling per la sicurezza delle applicazioniScanner di vulnerabilità: ecco come funzionanoWeb security: 5 motivi per cui è essenziale contro i ransomwareChe cos'è DevSecOps e come dovrebbe funzionare?Test di penetrazione vs scansione delle vulnerabilitàConsiderazioni sui test di correzione delle applicazioni WebQuattro modi in cui l'analisi AppSec aiuta i tuoi professionisti DevSecOpsQuattro modi per combattere il divario di competenze di sicurezza informaticaDove i framework di cybersecurity incontrano la sicurezza webCome costruire un piano di risposta agli incidenti informaticiRendi i tuoi utenti parte della soluzione di sicurezza webSei l'unico che può proteggere le tue applicazioni webNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaConvergenza Dev-Sec: i progressi e le sfide sulla strada per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?Sei l'unico che può proteggere le tue applicazioni webCos'è la sicurezza del sito Web: come proteggere il tuo sito Web dall'hackingRendi i tuoi utenti parte della soluzione di sicurezza webConvergenza Dev-Sec: la ricerca illustra i progressi per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?La differenza tra XSS e CSRFNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaPrevenzione e mitigazione XSSStop ai compromessi sulla sicurezza delle applicazioni webSfatare 5 miti sulla sicurezza informaticaBasta compromessi sulla sicurezza delle applicazioni webNozioni di base sulla sicurezza web: la tua applicazione web è sicura?Che cos'è l'iniezione dell’header HTTP?Fare shift left o no?Individuazione e correzione di falle di sicurezza in software di terze partiClassi di vulnerabilità Web nel contesto delle certificazioniScripting tra siti (XSS)Che cos'è un attacco CSRFChe cos'è una SQL Injection (SQLi) e come prevenirlaAttacchi di attraversamento di directoryChe cos'è la falsificazione delle richieste lato server (SSRF)?7 migliori pratiche per la sicurezza delle applicazioni WebBlack Hat 2021: la più grande minaccia alla sicurezza informaticaÈ ben fatto? Chiedi allo sviluppatore!Scegli la soluzione di sicurezza delle applicazioni web che fa per teSicurezza fai-da-te: lo stai facendo bene?Sulla sicurezza delle applicazioni web professionali per MSSPLa cattiva comunicazione è al centro delle sfide di AppSecImpostazione e raggiungimento degli obiettivi di sicurezza delle applicazioniMetriche di sicurezza informatica per le applicazioni WebCome evitare attacchi alla supply chainPerché la maggior parte delle misure di sicurezza delle applicazioni fallisceVuoi che la tua sicurezza sia costruita su scuse?Cos'è SCA e perché ne hai bisognoLa scansione ad hoc non è sufficienteEsposizione dei dati sensibili: come si verificano le violazioniHai paura dei test di sicurezza nell'SDLC?Vantaggi di Web Asset DiscoveryStrumenti di scansione delle vulnerabilità: perché non open source?Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23