Become a partner   | Request Support  | Contact Sales

Diventa Autore per CoreTech | Scopri di più





Considerazioni sui test di correzione delle applicazioni Web

07/07/22 CoreTech Blog

Sembra che la maggior parte delle discussioni sulla sicurezza delle applicazioni ruotino attorno alla scansione iniziale della vulnerabilità e ai test di penetrazione. Devi iniziare da qualche parte. Il fatto è che molte persone spesso si fermano a quel punto. Le vulnerabilità vengono scoperte, i risultati vengono trasmessi agli sviluppatori, ai DevSecOps o ad altro personale tecnico, e il gioco è fatto... almeno fino alla prossima volta, diverse settimane, mesi o anche un anno o giù di lì, quando il processo ricomincia. Un approccio davvero solido, ma non è sufficiente per un buon programma di test di sicurezza web.

L'altro elemento per garantire la resilienza del web e un programma globale di sicurezza delle informazioni solido è il follow-through. Questo si presenta sotto forma di test di riparazione. Non diversamente dall'avere un'anomalia negli esami del sangue o un intervento chirurgico complicato, che richiedono entrambi il follow-up con un operatore sanitario, la convalida della riparazione gioca un ruolo importante ma spesso trascurato nella sicurezza delle applicazioni web. È questo seguito che così tante persone danno per scontato che può, a lungo termine, aiutarti a ottenere i risultati di cui hai bisogno.

Perché anche questo è un grosso problema? Perché condivido le mie opinioni sui test di correzione delle applicazioni Web? Perché, sorprendentemente, così tante persone non lo fanno. Molte aziende, in particolare le piccole e medie imprese che potrebbero non disporre di personale dedicato alla sicurezza insieme agli strumenti e alle competenze adeguati per svolgere il lavoro, faticano a tenere il passo con le scansioni e i test iniziali. Può essere ancora più difficile da seguire per garantire che le vulnerabilità scoperte di recente siano state risolte. Mi consulto spesso con grandi aziende con centinaia, se non migliaia, di applicazioni web. Queste aziende hanno spesso una gestione delle vulnerabilità più formalizzata programma, eppure lottano ancora con le stesse sfide dei test di riparazione. Indipendentemente dalle dimensioni dell'azienda o dal settore in cui opera, budget e tempo (più appropriatamente, gestione del tempo) spesso impediscono allo staff tecnico di tornare indietro e confermare che le vulnerabilità iniziali scoperte sono state risolte.

Banner

Questo è problematico per molte ragioni. La più ovvia delle quali è che le vulnerabilità, anche quelle critiche, permangono e creano rischi inutili. Anche se potrebbero essere state implementate correzioni, non c'è modo di sapere con certezza se il difetto originale è stato risolto correttamente. Inoltre, non ci sono rapporti o controlli di convalida manuali per fornire prove che i problemi siano stati risolti. È difficile migliorare quando non si misurano i progressi. Ancora più problematica è la realtà che ne deriva in termini di difendibilità. Una volta scoperte e riconosciute le vulnerabilità web, esiste la responsabilità intrinseca di risolverle. Se non immediatamente, sicuramente a lungo termine, soprattutto quando viene dimostrato in un tribunale che la risoluzione delle vulnerabilità e il miglioramento della sicurezza non erano una priorità e la direzione esecutiva ha guardato dall'altra parte, non riuscendo a risolvere i problemi noti.

I test di correzione della vulnerabilità Web non devono essere un onere. Se disponi di buoni strumenti, in particolare scanner di vulnerabilità web in grado di eseguire test rapidi e segnalare la risoluzione delle vulnerabilità, sei a metà strada. L'altra metà consiste nell'integrare i test di riparazione nei processi e nel renderli una priorità in modo che sia assegnato il tempo necessario per portare a termine le cose.

Quando si esegue il test di riparazione, probabilmente non avrà senso ripetere il test ogni volta, almeno all'inizio. Concentrati sulle vulnerabilità web che sono sia urgenti che importanti. In altre parole, grossi difetti come SQL injection e cross-site scriptingche si trovano sui tuoi sistemi più business-critical come il tuo sito di marketing o il tuo sistema ERP. Ho visto molte persone provare a ripetere il test e risolvere ogni singolo risultato da uno scanner di vulnerabilità o da un rapporto di test di vulnerabilità e penetrazione. Molte persone sono alla ricerca di un rapporto pulito in modo da poter dimostrare i loro sforzi alla direzione. Un compito nobile ma, per me, è un esercizio di futilità. Ciò è particolarmente vero all'inizio quando non sono disponibili solidi standard e processi di gestione delle vulnerabilità e di convalida della correzione. A lungo termine, è possibile e ragionevole pensare di poter eseguire test di riparazione su ogni singolo risultato in modo da risolvere ogni singola vulnerabilità? Può darsi. Devo ancora imbattermi in un'organizzazione che abbia i mezzi per farlo, ma è un obiettivo degno se pensi che possa essere raggiunto.

L'ultima cosa che vuoi fare è preparare te stesso e la tua attività al fallimento. Per evitare ciò, assicurati di eseguire i test di riparazione entro un periodo di tempo ragionevole dopo aver scoperto le vulnerabilità iniziali. Concentrati almeno sulle vulnerabilità con priorità più alta scoperte nelle tue applicazioni Web pubbliche. Il test di convalida della riparazione non deve essere, e non dovrebbe essere, un'altra valutazione completa. Potrebbe trattarsi semplicemente di una scansione rapida o di un controllo manuale che richiede solo pochi minuti. Creare standard per i test di riparazione. Fai evolvere i tuoi processi nel tempo. Concentrarsi su un impegno relativamente piccolo in quest'area può fornire enormi guadagni a lungo termine per la tua organizzazione e il tuo programma di sicurezza generale.


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