Gestione delle vulnerabilità
Sviluppa pratiche efficaci in materia di vulnerabilità.
Panoramica
Questo documento tecnico illustra diverse pratiche di gestione delle vulnerabilità come scansioni delle vulnerabilità, test di penetrazione e scansioni delle vulnerabilità del codice. Questo documento esplorerà anche i processi per ripristinare la disponibilità e l'accesso dopo un'interruzione del servizio dovuta a un incidente.
Requisiti della politica di protezione dei dati
As part of Amazon’s Data Protection Policy (DPP) (DPP), developers have to implement vulnerability scans at minimum semi-annually, penetration tests yearly, code vulnerability scans prior to release of new code, features, or products, and to ensure they can restore availability and access to Personal Identifiable Information (PII) within hours. This is to avoid exposure of sensitive data, including PII. Every SP-API developer needs to ensure that vulnerable points such as public-facing websites, interfaces, servers, and new features have the expected level of security and protection even before release.
Gestione delle vulnerabilità
Gli sviluppatori devono creare e mantenere un piano o un run-book per rilevare e correggere le vulnerabilità. Gli sviluppatori devono proteggere l'hardware fisico contenente informazioni personali dalle vulnerabilità tecniche eseguendo scansioni delle vulnerabilità e correggendole in modo appropriato. Gli sviluppatori devono eseguire una scansione delle vulnerabilità almeno ogni 180 giorni, un test di penetrazione almeno ogni 365 giorni e scansionare il codice per individuare eventuali vulnerabilità prima di ogni versione. Inoltre, gli sviluppatori devono controllare le modifiche all'hardware di storage testando, verificando le modifiche, approvando le modifiche e limitando l'accesso a chi può eseguire tali azioni. Gli sviluppatori devono disporre di procedure e piani appropriati per ripristinare la disponibilità e l'accesso alle PII in modo tempestivo in caso di incidente fisico o tecnico.
Scansioni delle vulnerabilità
Una scansione delle vulnerabilità è il processo di identificazione, scoperta, analisi e segnalazione degli accessi all'host, dei punti deboli e delle lacune di rete per le istanze o il software in esecuzione sull'applicazione.
È essenziale in termini di sicurezza verificare che i dispositivi/le istanze rivolti al pubblico siano protetti dai malintenzionati. In uno scenario ideale, le scansioni possono essere eseguite con strumenti di scansione delle vulnerabilità per identificare/classificare i fattori di rischio e i possibili vettori di attacco all'interno della rete (comprese le risorse software e hardware).
Here are the top ten vulnerabilities according to the Open Web Application Security Project (OWASP) for 2021 and associated Common Weakness Enumerations (CWE):
CWE | Punto di vulnerabilità | Breve descrizione |
---|---|---|
A01 | Controllo degli accessi non funzionante | L'utente esegue un'azione a cui non dovrebbe poter accedere. |
A02 | Errori crittografici | Pratiche crittografiche carenti o deboli. |
A03 | Iniezione | Gli hacker sono in grado di inserire dati e manipolarli all'interno di una rete. |
A04 | Design non sicuro | Mancanza di pianificazione durante la fase di progettazione della rete. |
A05 | Microconfigurazioni di sicurezza | Impostazioni di sicurezza in database, librerie o server non impostate, che potrebbero portare a una vulnerabilità. |
A06 | Componenti vulnerabili e obsoleti | Versioni precedenti o non supportate del software o del sistema operativo. |
A07 | Errori di identificazione e autenticazione | Mancanza di controlli di accesso degli utenti e gestione delle credenziali. |
A08 | Errori di integrità del software e dei dati | Nessuna protezione contro le violazioni dell'integrità. |
A09 | Errore di registrazione e monitoraggio sicuri | Nessun servizio di monitoraggio che rende difficile l'identificazione delle violazioni e degli attacchi in uscita. |
A10 | Falsificazione delle richieste lato server (SSFR) | URL non verificato fornito da un utente che obbliga un'applicazione a inviare richieste che aggirano la sicurezza della rete. |
Refer to OWASP – Vulnerability Scanning Tools for a list of free and paid scanning tools.
Una volta completate le scansioni, gli sviluppatori devono dare priorità alle vulnerabilità in base al livello di impatto sulla sicurezza e lavorare per correggerle di conseguenza.
-
Scansioni di vulnerabilità esterne: Le scansioni esterne hanno lo scopo di verificare le vulnerabilità in punti esterni/pubblici come porte, siti Web, reti e applicazioni.
-
Scansioni interne delle vulnerabilità: Le scansioni interne offrono visibilità sulle possibili lacune di sicurezza all'interno di una rete privata.
-
Scansioni intrusive e non intrusive: Le scansioni non intrusive eseguono la scansione di un target specifico, ad esempio il traffico di rete o la versione di un database, ma non influiscono sui livelli di servizio in quanto controllano solo le informazioni senza sfruttare la vulnerabilità. Una scansione intrusiva ha lo scopo di sfruttare la vulnerabilità al massimo livello e fornire maggiori informazioni sulle vulnerabilità rilevate, ma interrompe anche i livelli di servizio, quindi utilizzala in un ambiente controllato.
Amazon Inspector
Amazon Inspector is a scalable vulnerability management tool which scans workloads and unintended network exposures to verify that there are no vulnerabilities in operating systems running EC2 instances.
Amazon Inspector fornisce report di individuazione delle vulnerabilità quasi in tempo reale utilizzando fattori CVE (Common Vulnerabilities and Exposure) aggiornati e controllando diversi linguaggi di codifica come Java, Python e Node.js. Gli sviluppatori che utilizzano Amazon Inspector possono utilizzarlo per la convalida della conformità di programmi come i certificati PCI, ISO e CSA STAR.
Amazon Guard
Amazon’s Security team developed Amazon’s SP-API-Guard as an application that runs in AWS instances to check and asses security compliance with Amazon’s DPP. SP-API Guard also provides a recommendation report of any security gap it finds within a day to an S3 bucket. This reduces the effort for manual Data Security Assessments and remediation plan times while providing recommended solutions for vulnerabilities found.
Test di penetrazione
Il penetration test (pen test) è un modo per verificare in un ambiente simulato/controllato eventuali vulnerabilità in diversi punti delle applicazioni o delle reti. Questo viene fatto per confermare quali vulnerabilità possono essere sfruttate dai malintenzionati.
Il pen test consiste nelle seguenti fasi:
-
Fase di pianificazione: Il team stabilisce gli obiettivi e l'ambito dei pen test dei tester. Tutte le parti devono essere a conoscenza dei prossimi test.
-
Fase di scansione/scoperta: I pen tester avviano il processo di riconoscimento della rete e di ispezione del codice.
-
Fase di penetrazione: Il pen tester tenta di accedere alla rete/alle istanze utilizzando diversi tipi di attacchi come SQL injection, cross-site scripting e backdoor per sfruttare le vulnerabilità.
-
Fase di analisi/report: Il pen tester crea un report con informazioni dettagliate sulle azioni intraprese per violare la sicurezza della rete e sulle vulnerabilità rilevate. Il pen tester deve includere nel report una sezione sulle azioni consigliate.
-
Fase di bonifica/pulizia: Il team responsabile prende l'iniziativa e inizia a lavorare sulla correzione delle vulnerabilità segnalate dopo il completamento dei pen test.
Come ulteriore passaggio di sicurezza per garantire che le vulnerabilità vengano corrette o corrette, gli sviluppatori eseguono un secondo test dopo la fase di correzione per assicurarsi che non vi siano elementi lasciati indietro o incustoditi.
OWASP also offers a penetration test guide (OWASP ZAP) for developers who want to know more on how to apply pen tests at an application level and for their network components such as firewalls and ports.
Scansioni delle vulnerabilità del codice
Le scansioni delle vulnerabilità del codice hanno lo scopo di ridurre i rischi quando viene rilasciata una nuova funzionalità/prodotto. Gli sviluppatori possono garantire che non vi siano errori, problemi tecnici o lacune di sicurezza durante l'implementazione del codice utilizzando i seguenti strumenti di scansione del codice:
-
Test di sicurezza delle applicazioni statiche (SAST): revisione del codice senza doverlo eseguire. SAST verifica la modalità di scrittura del codice per evidenziare eventuali problemi di sicurezza.
-
Test dinamico di sicurezza delle applicazioni (DAST): A differenza di SAST, DAST controlla il codice in un'applicazione in esecuzione simulando attacchi con iniezioni dannose di payload. DAST aiuta gli sviluppatori a identificare le vulnerabilità all'interno di un'applicazione in esecuzione.
-
Test applicativo interattivo (IAST): IAST verifica le funzionalità delle applicazioni in tutti gli ambienti di test. Ciò facilita l'implementazione e la scalabilità in quanto aiuta a ridurre possibili tempi di inattività o interruzioni del servizio affrontando le vulnerabilità prima del rilascio.
Questi strumenti devono seguire gli standard forniti da OWASP per verificare la sicurezza delle applicazioni rispetto ai dieci principali rischi per la sicurezza. Gli sviluppatori devono procedere con la scansione del codice per identificare, classificare e dare priorità a eventuali falle di sicurezza che influiscono o interrompono il servizio dopo il lancio del prodotto.
Piano di disaster recovery
To ensure that application users are not affected by incidents (technical or physical) developers must have a plan that covers actions on how to restore availability and access to PII data in a short time, taking in consideration Recovery Time Objective (RTO) and Recovery Point Objective (RPO). AWS offers guidance in Establishing RTO and RPO Targets for Cloud Applications.
-
A: Il tempo impiegato dagli sviluppatori per ripristinare i normali livelli di servizio per gli utenti delle applicazioni. Ciò può essere ottenuto mediante la ridondanza all'interno delle istanze/servizi di rete che sono fondamentali per la funzionalità dell'applicazione.
-
PRO: Il momento in cui gli sviluppatori possono ripristinare i dati, in altre parole, quanti dati è accettabile perdere dopo un incidente. Un aspetto fondamentale di questo obiettivo è disporre di uno o più backup dei dati in luoghi diversi ed eseguirli due volte a settimana, se possibile.
Developers are expected to use recovery strategies and test them to meet objectives (RTO and RPO). AWS Resilience Hub is an AWS service that helps to establish RTO and RPO targets, and it analyzes applications against those targets.
Conclusione
La gestione delle vulnerabilità è uno standard di sicurezza essenziale. Le scansioni di vulnerabilità e i test di penetrazione aiutano a identificare e ridurre i possibili rischi all'interno di un ambiente di rete e delle istanze applicative. Gli sviluppatori devono eseguire scansioni di vulnerabilità e pen test almeno una volta all'anno in conformità ai requisiti del DPP. La pratica di condurre queste valutazioni aiuta gli sviluppatori ad aumentare la loro maturità in materia di sicurezza e a rispettare gli standard a cui possono far fronte, ad esempio le migliori pratiche normative o di settore.
Gli sviluppatori devono eseguire una scansione del codice prima del rilascio di funzionalità o prodotti. I test devono essere eseguiti in un ambiente isolato e controllato per garantire che non vi siano lacune di sicurezza per le nuove versioni e che nessun dato sia esposto.
La disponibilità di backup, istantanee o immagini aiuta a ridurre l'impatto della perdita di dati PII a causa di un incidente. Garantire la resilienza dei servizi applicativi riduce il tempo necessario per ripristinare l'accesso e la disponibilità ai dati PII.
Updated 23 days ago