Cinque errori frequenti nella protezione delle applicazioni

0
61

This post is also available in: Inglese Francese Tedesco Portoghese, Brasile Spagnolo Russo

Ogni anno, le aziende spendono molti soldi in tecnologie di sicurezza sempre più avanzate per proteggere la riservatezza dei dati e l’esperienza dell’utente. I CISO puntano sull’apprendimento automatico, l’automazione, l’orchestrazione dell’analisi e la risposta agli eventi e si fidano dei provider di cloud pubblici e dei loro system integrator. Tuttavia, si verificano ancora violazioni dei dati.

errore: “Pensavo che un WAF fosse sufficiente

Si ignora che le minacce aggiuntive alle applicazioni oramai da tempo vanno ben oltre gli exploit che sfruttano i primi 10 rischi per le applicazioni Web elencati da OWASP. Sì, iniezioni, scripting cross-site, CSRF, dirottamento di sessione e cookie poisoning e altri simili sono ancora molto validi, specialmente quando ci sono così tanti sistemi legacy senza patch in giro. I team di sviluppo mettono più enfasi sull’agilità che sulla sicurezza. Tuttavia, la superficie di attacco, e quindi l’esposizione ai rischi, è oggi molto maggiore.

Altre tre minacce da combattere:

  1. Bot dannosi: un quarto del traffico Internet è generato da bot dannosi[CB1] . Con il carico sulle reti e i persistenti tentativi di prendere il controllo degli account degli utenti, manipolare le transazioni online e rubare dati sensibili, le organizzazioni non possono fare affidamento solo sui firewall delle loro applicazioni Web o, peggio, perdere tempo nella creazione di script personalizzati fatti in casa e devono invece iniziare a pensare a una tecnologia di gestione dei bot dedicata. Una tecnologia in grado di lasciare entrare con precisione i bot buoni e respingere quelli nefasti.
  2. Protezione API: sistemi e applicazioni interconnessi che scambiano dati tramite API. Questi sono in genere attendibili e quindi possono essere facilmente trascurati. Il furto di dati tramite API sottoprotette ha già fatto notizia diverse volte (PaneraBread, Venmo, Boots e altro). Le organizzazioni non sempre conoscono tutte le API che hanno, che tipo di dati stanno elaborando e chi può accedervi. Per questo hanno bisogno di un buon strumento per scoprire, classificare e proteggere tutti i loro endpoint API.
  3. Denial of Service – ne è passato di temo da quando questo era un problema degli operatori di rete. I server Web e le risorse digitali sono ora spesso presi di mira da avversari disposti a interrompere il servizio o a distruggere un sito Web. Ha quindi assolutamente senso integrare la protezione ddos ad alto volume come parte della strategia di sicurezza delle applicazioni.

2o errore: “Ero tentato di accorpare il mio WAF al servizio CDN”

Sì, ha perfettamente senso. Se ti interessano le prestazioni più dei dati sensibili ai clienti, questa potrebbe essere la strada da percorrere. Ma se hai una responsabilità riguardante la protezione dei dati dell’azienda e degli utenti, devi ripensare a questo compromesso. Per la natura stessa dell’architettura, il WAF all’estremità della rete non vede il traffico per applicazione e quindi non può applicare alcun meccanismo di apprendimento, rilevamento di anomalie e sicurezza positiva il che significa nessuna protezione zero-day. È probabile che queste applicazioni perdano dati poiché non sono protette da tecniche di attacco sconosciute.
Negli ambienti cloud pubblici, il divario è ancora maggiore in quanto la tecnologia WAF fornita dal provider IaaS, non un fornitore specializzato, e di solito ha una posizione bassa nei rapporti degli analisti. Per saperne di più leggi i nostri post precedenti

3° errore: “Posso applicare la stessa sicurezza su tutte le piattaforme”

Questo è un errore che si paga caro. Per usare la stessa policy di sicurezza delle applicazioni in tutti gli ambienti – data center, cloud privato, Azure, AWS, GCP e Alibaba o Tencent – le aziende sono costrette a fare un compromesso. Il motivo è che ogni ambiente e ogni provider richiedono modifiche, come autorizzazioni di accesso, protezione dell’infrastruttura, meccanismi di autenticazione e autorizzazione, controlli del traffico bot, strumenti di sicurezza API nel back-end e altro ancora.

Se si sceglie la coerenza (come un servizio basato su cloud), si deve fare un compromesso sia nella user experience (latenza) che nella sicurezza (vedi n. 2 sopra). La scelta dell’ottimizzazione della sicurezza si tradurrà in uno sforzo per adattare le soluzioni giuste a ciascun ambiente e quindi dedicare tempo e risorse per aggiornarle costantemente e applicare la politica di sicurezza che il CISO ama implementare.

Questa sfortunata situazione porta ad uno scenario di sicurezza che ricorda il groviera e i suoi buchi, e le cui potenziali conseguenze possono essere indovinate in anticipo. Ecco alcune pratiche consigliate.

[Ti è piaciuto questo post? Abbonati ora per ricevere ogni settimana gli ultimi contenuti Radware via e-mail e per avere accesso esclusivo ai Contenuti Premium di Radware. ]

4° errore: “Pensavo di poter gestire tutte le eccezioni da solo”

I firewall delle applicazioni Web storicamente soffrono di cattiva reputazione, ampiamente meritata. Troppe regole legittime sono state bloccate su regole e configurazioni non in linea con i requisiti aziendali. Quando ciò accade, il costo può essere devastante: una cattiva user experience porta a un atteggiamento negativo nei confronti del marchio e alla diminuzione dei tassi di conversione. Il TCO della gestione in-house di un WAF può essere molto elevato a causa di questo lavoro indiretto richiesto e per di più la materia va affidata a degli esperti, specialmente quando si valutano tutte le minacce alla sicurezza sopra menzionate. Uno sguardo meno esperto infatti non può vedere i troppi avvisi provenienti dalle diverse soluzioni. Una strategia appsec consolidata gestita da esperti con automazione avanzata e actionable analytics riduce sostanzialmente il TCO offrendo sicurezza in tempi rapidi.

[Se ti interessa ti consigliamo: Come ottenere la protezione delle applicazioni con AWS/Azure CDN]

5° errore: “Pensavo che DevOps mi avrebbe ascoltato”

Alcuni attacchi non hanno successo grazie a una posizione di sicurezza debole e disgiunta a sua volta causata da processi interrotti e conflitti interni. Le dinamiche dello sviluppo delle applicazioni e delle pratiche di sicurezza odierne sono tali che le soluzioni di sicurezza e soprattutto il personale non possono tenere il passo. Dal punto di vista degli sviluppatori, ci sono così tanti strumenti disponibili per progettare la pipeline CI/CD perfetta con strumenti di provisioning, test e orchestrazione automatizzati. L’agilità è tutta rivolta in avanti, al futuro: la prossima versione, la prossima patch, la prossima correzione di bug, senza rallentare per ispezionare ogni transazione e ogni modulo. Poiché la produttività viene sempre al primo posto, la sicurezza è costretta ad adeguarsi. Tuttavia, questo è un equilibrio delicato che ogni organizzazione gestisce in modo diverso. Poiché DevOps sta acquisendo maggiore influenza sulle decisioni relative alla sicurezza, il personale addetto alla sicurezza delle informazioni deve tenere conto del fatto che una soluzione per la sicurezza delle applicazioni deve fare molto di più che bloccare gli attacchi: dovrebbe integrarsi bene nell’ecosistema SDLC ed essere adattiva: mettere a punto la politica ogni volta che viene introdotta una modifica all’applicazione. Dovrebbe anche consentire a DevOps di avere la visibilità di cui ha bisogno sulle metriche delle prestazioni e sull’automazione in tutti gli ambienti. In questo modo, sistemiamo il processo e facciamo contenti tutti.

Evitando questi errori si svilupperà una strategia di sicurezza delle applicazioni che è:

  • Coerente
  • Trasparente
  • Adattiva
  • Efficace
https://blog.radware.com/wp-content/uploads/2021/06/Hackers-book1-v1a-1.png

Scarica la prima serie di Hacker’s Almanac 2021 di Radware.

LEAVE A REPLY

Please enter your comment!
Please enter your name here