Sempre più frequentemente le aziende migrano le loro applicazioni business critical al cloud e gli avversari stanno adattando le loro tattiche di conseguenza. All’interno del cloud, è evidente che i criminali informatici stanno puntando sulle applicazioni software: i dati del settore mostrano che 8 delle 10 principali violazioni nel 2023 erano correlate alle applicazioni.
Quelle più rilevanti, ovvero le applicazioni business critical, solitamente elaborano grandi quantità di dati sensibili, tra cui informazioni sui clienti, proprietà intellettuale e altri dati critici. Le applicazioni spesso presentano vulnerabilità o errori di configurazione, lasciando esposte importanti informazioni agli attori delle minacce. Gli avversari lo sanno e di conseguenza molti gruppi di cybercrime concentrano i loro attacchi su questo tipo di software.
È importante, quindi, che le aziende adottino misure per proteggere le applicazioni business critical per impedire che i dati sensibili finiscano nelle mani sbagliate.
Indice degli argomenti
Identificare le applicazioni business critical
Le applicazioni business critical sono fondamentali per le operations di un’azienda: tipicamente elaborano grandi quantità di informazioni sensibili, generando ricavi per l’azienda.
Se una applicazione business critical viene violata, l’azienda madre potrà incorrere in multe, perdita di dati, danni alla reputazione, perdita di clienti e altro ancora. Inoltre, l’azienda potrebbe subire perdite sui ricavi se il software andasse offline in modo imprevisto e i clienti non potessero effettuare transazioni sulla piattaforma.
Alcuni esempi di critical application comprendono applicazioni di trading, siti di e-commerce, software sanitari e qualsiasi altro software personalizzato che elabora informazioni private o business critical data.
Una volta che le applicazioni sviluppate su misura sono considerate “business critical”, dovrebbero essere considerate una priorità assoluta per ciò che riguarda il monitoraggio della sicurezza e le revisioni.
Configurare un’infrastruttura digitale sicura
Proteggere le macchine che eseguono le applicazioni business critical è un compito complesso a causa degli innumerevoli componenti che vi gravitano attorno.
Risulta importante considerare ciascuna delle seguenti necessità infrastrutturali:
- Network segmentation
- Firewall
- Patching del sistema operativo e delle macchine virtuali (VM)
- Crittografia
- Gestione delle password
Limitare la capacità di un attaccante di muoversi lateralmente attraverso il network è fondamentale per fermare le violazioni. Isolando gli asset digitali e richiedendo l’autorizzazione per accedere alle critical applications, è possibile ridurre la probabilità di riuscita di un attacco.
Inoltre, i network packets possono essere respinti grazie a liste di controllo all’accesso e firewall, compresi i firewall delle applicazioni web.
I sistemi operativi e le macchine virtuali (VM) devono essere regolarmente aggiornati. Questi sistemi costituiscono la base su cui tutti gli altri software vengono eseguiti; di conseguenza, risultano bersagli appetibili per gli avversari; perciò, tutte le nuove vulnerabilità dovranno essere patchate ogni qualvolta vengano riconosciute e divulgate.
Nelle configurazioni cloud note come “platform as a service” (PaaS), il cloud provider aggiorna automaticamente il sistema operativo e la VM per patchare le vulnerabilità. Mentre con le implementazioni on-premise e altre configurazioni cloud note come “infrastructure as a service” (IaaS), è l’utente finale la figura responsabile del patching dei propri sistemi.
I dati possono essere memorizzati in modo sicuro per una ulteriore protezione anche in caso di violazioni.
Assicurarsi che sia i dati sensibili archiviati che quelli in transito siano crittografati e che le password siano hashate, riduce le probabilità che un attaccante riesca nel tentativo di estrarre informazioni preziose.
Inoltre, documenti segreti come chiavi SSH e certificati devono rimanere protetti. Un’infrastruttura digitale sicura crea un ambiente protetto per eseguire le applicazioni business critical.
Limitare i permessi di accesso alle sole persone necessarie
La maggior parte degli attacchi informatici inizia con credenziali rubate. Limitando sia l’accesso generale che amministrativo ai dipendenti è possibile ridurre notevolmente il rischio di compromissione.
Le funzioni di un’applicazione determinano la strategia di accesso. Le applicazioni aziendali interne spesso utilizzano il controllo degli accessi role-based (RBAC) per consentire o negare l’accesso ad altri reparti. Per un’applicazione business-to-consumer, la strategia di accesso è diversa: le applicazioni che servono un’ampia clientela spesso concedono l’accesso a qualsiasi utente che scelga di registrarsi.
Indipendentemente da chi può accedere, è fondamentale assicurarsi che gli utenti possano accedere solo alle sezioni dell’applicazione d’interesse per loro. Solitamente le funzionalità base sono disponibili a tutti gli utenti, mentre le funzionalità più specifiche sono disponibili per un’utenza limitata.
Per esempio, le funzioni amministrative possono essere limitate a un piccolo sottoinsieme di persone che lavorano nel dipartimento IT e all’azienda madre.
Inoltre, è consigliato controllare e revocare periodicamente l’accesso agli utenti che non hanno più bisogno di accedere alle applicazioni business critical, come i dipendenti licenziati.
Una volta che gli utenti sono autenticati, viene fornito un token di accesso all’applicazione. Questi token identificano in maniera univoca un individuo, e consentono al software di autorizzare le richieste degli utenti, anziché richiedere un nome utente e una password ad ogni accesso.
Gli attaccanti cercano di rubare i token di accesso per poter sfruttare l’accesso di utenti iscritti e rubare dati sensibili dal software.
È necessaria molta attenzione per proteggere i token di accesso dagli attaccanti. La richiesta di connessioni HTTPS per il rilascio del token e l’impostazione di scadenze dei token sono comuni meccanismi di difesa.
Inoltre, i permessi degli utenti dovrebbero essere testati ad ogni richiesta verso il server. Ogni interfaccia di programmazione delle applicazioni (API) dovrebbe prevedere l’autenticazione dell’identità dell’utente e l’autorizzazione per accedere alle informazioni richieste.
Stabilire permessi di accesso efficaci per le applicazioni business critical è essenziale per evitare utenti indesiderati nel software e per fermare le violazioni.
Monitorare proattivamente le attività sospette
Le applicazioni business critical sono di grande interesse per gli avversari. È essenziale quindi implementare una soluzione di monitoraggio efficace per rilevare gli attacchi e fermare gli accessi sospetti.
Ogni applicazione software deve disporre di un host localizzato da qualche parte.
Aggiungendo un agente per il runtime protection ai server che eseguono le applicazioni business critical, i security team saranno in grado di fermare l’attività pericolosa. Indicatori comuni di attacco come la persistenza, il movimento laterale e l’attacco di enumerazione dovrebbero preoccupare l’organizzazione.
Le informazioni in tempo reale consentono ai team di rilevamento e risposta di intercettare attività sospette prima che avvenga l’estrazione di dati.
Il software on-premise dispone di soluzioni per il rilevamento e risposta degli endpoint, mentre le applicazioni native in cloud utilizzano la protezione del workload cloud per fermare gli attacchi in tempo reale.
Migliorare i test di sicurezza nello sviluppo software
Implementare controlli di sicurezza nel primo processo di sviluppo aiuta a ridurre il rischio in produzione. Attraverso lo shift left e integrando scanner di vulnerabilità nella linea di sviluppo software, i team di sviluppo possono individuare e correggere i bug di sicurezza in anticipo.
I security team che misurano la postura di sicurezza in produzione, possono misurare l’effetto che lo shift left ha sul rischio aziendale. Integrare strumenti di scansione delle vulnerabilità è necessario nello sviluppo net-new, poiché le vulnerabilità sono più facili da mitigare durante lo sviluppo iniziale.
Le applicazioni software personalizzate contengono codice nativo e codice di terze parti, spesso noto come “open source”. Il proprietario del software personalizzato garantisce che i pacchetti importati non contengano vulnerabilità e esposizioni comuni (CVE).
Inoltre, il team di sviluppo può introdurre vulnerabilità nel proprio codice sviluppato internamente. È responsabilità aziendale garantire che i propri sviluppatori sviluppino un codice sicuro indipendentemente dalla deployment location.
Risolvere i rischi immediati in produzione
La postura di rischio dell’applicazione è una combinazione di configurazioni errate dell’infrastruttura, vulnerabilità di sicurezza, logica aziendale e sensibilità dei dati. Analizzare la postura di rischio attuale delle applicazioni business critical dovrebbe essere una priorità.
Le configurazioni errate e le vulnerabilità sono diverse, ma introducono problemi di sicurezza simili. Le configurazioni errate risultano da impostazioni infrastrutturali fragili che aumentano la probabilità di accessi indesiderati.
Le configurazioni errate comuni includono credenziali predefinite, traffico in ingresso non limitato, storage buckets pubblici e chiavi SSH plaintext.
Le vulnerabilità del software, d’altra parte, sono difetti di sicurezza nel codice che un attaccante può sfruttare.
La falla per essere sfruttata deve essere accessibile. Ad esempio, una CVE che abilita l’esecuzione remota del codice è più pericolosa quando presente in un microservizio esposto al pubblico. I trust bundaries, che sono “confini” teorici, definiscono l’affidabilità del flusso di dati in entrata da una fonte.
Le applicazioni business critical possono essere sfruttate più facilmente quando le loro vulnerabilità sono ai margini di un trust boundary. Il rischio di produzione aumenta quando le applicazioni sono connesse tramite internet pubblico o software di terze parti.
Comprendere i flussi di dati e le API è cruciale nella valutazione del rischio aziendale. I security team possono prendere decisioni efficaci quando comprendono i dati elaborati durante varie fasi di un’applicazione business critical.
Le API che trasmettono payload sensibili rappresentano un rischio maggiore rispetto a quelle prive di dati sensibili. Allo stesso modo, i database con informazioni personali sensibili presentano un rischio maggiore. Unire la logica aziendale con i dati sensibili consente ai security team di prendere decisioni più informate.
Monitorare i cambiamenti in produzione
Quando le modifiche al codice alterano le applicazioni personalizzate, è indispensabile tenere traccia dei cambiamenti apportati alla loro posizione di rischio.
I nuovi flussi di dati e le API possono avere grande influenza sull’esposizione di dati sensibili. Ancora più difficili da gestire sono le modifiche ai flussi di dati e alle API esistenti: piccoli aggiornamenti possono presentare rischi enormi, come la rimozione accidentale dell’autenticazione da un’API o la restituzione di dati sensibili nel payload di un’API per la prima volta.
La maggior parte del codice non viene creato internamente. In effetti, i software open source rappresentano oltre l’80% delle stringhe di codice delle moderne applicazioni software. Con la modifica delle versioni delle librerie e la prima importazione di nuove librerie, i CVE presenti in un’applicazione cambieranno. Comprendere l’impatto sull’azienda e la probabilità di sfruttamento di ogni CVE in produzione consente ai security team di dare priorità ai loro interventi. Il mantenimento di un monitoraggio costante della postura di rischio della produzione consente ai security team di rimanere sincronizzati con le loro controparti di sviluppo del software e di rispondere rapidamente ai cambiamenti pericolosi.
