Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Esempi di valutazione e correzione dei risultati di sicurezza
Questa sezione fornisce esempi del processo di triage per i team addetti alla sicurezza, al cloud e alle applicazioni. Descrive i tipi di risultati che ogni team affronta di solito e fornisce un esempio di come rispondere. Sono incluse anche linee guida di alto livello per la risoluzione dei problemi.
**Topics**
+ [Esempio di team di sicurezza: creazione di una regola di automazione CSPM Security Hub](security-team-example.md)
+ [Esempio di team cloud: modifica delle configurazioni VPC](cloud-team-example.md)
+ [Esempio di team applicativo: creazione di una regola AWS Config](application-team-example.md)
# Esempio di team di sicurezza: creazione di una regola di automazione CSPM Security Hub
Il team di sicurezza riceve i risultati relativi al rilevamento delle minacce, inclusi GuardDuty i risultati di Amazon. Per un elenco completo dei tipi di GuardDuty ricerca classificati per tipo di AWS risorsa, consulta [Finding types](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) nella GuardDuty documentazione. I team addetti alla sicurezza devono conoscere tutti questi tipi di risultati.
Per questo esempio, il team addetto alla sicurezza accetta il livello di rischio associato ai risultati di sicurezza in un documento Account AWS che viene utilizzato esclusivamente per scopi di apprendimento e non include dati importanti o sensibili. Il nome di questo account è`sandbox`, e l'ID dell'account è`123456789012`. Il team addetto alla sicurezza può creare una regola di AWS Security Hub CSPM automazione che sopprime tutti i GuardDuty risultati di questo account. Possono creare una regola da un modello, che copre molti casi d'uso comuni, oppure creare una regola personalizzata. In Security Hub CSPM, consigliamo di visualizzare in anteprima i risultati dei criteri per confermare che la regola restituisca i risultati previsti.
**Nota**
Questo esempio evidenzia la funzionalità delle regole di automazione. Non è consigliabile eliminare tutti i GuardDuty risultati relativi a un account. Il contesto è importante e ogni organizzazione deve scegliere quali risultati eliminare in base al tipo di dati, alla classificazione e ai controlli di mitigazione.
Di seguito sono riportati i parametri utilizzati per creare questa regola di automazione:
+ **Regola:**
+ **Il nome della regola** è `Suppress findings from Sandbox account`
+ **La descrizione della regola** è `Date: 06/25/23 Authored by: John Doe Reason: Suppress GuardDuty findings from the sandbox account`
+ **Criteri:**
+ `AwsAccountId` = `123456789012`
+ `ProductName` = `GuardDuty`
+ `WorkflowStatus` = `NEW`
+ `RecordState` = `ACTIVE`
+ **Azione automatizzata:**
+ `Workflow.status` è `SUPPRESSED`
Per ulteriori informazioni, consulta [Regole di automazione](https://docs.aws.amazon.com/securityhub/latest/userguide/automation-rules.html) nella documentazione CSPM di Security Hub. I team di sicurezza hanno a disposizione molte opzioni per indagare e correggere i risultati delle minacce rilevate. Per una guida completa, consulta la [AWS Security Incident Response](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html) Guide. Ti consigliamo di consultare questa guida per confermare di aver stabilito solidi processi di risposta agli incidenti.
# Esempio di team cloud: modifica delle configurazioni VPC
Il team cloud è responsabile della valutazione e della correzione dei risultati di sicurezza che presentano tendenze comuni, come le modifiche alle impostazioni AWS predefinite che potrebbero non essere adatte al caso d'uso. Questi risultati tendono a influire su molte Account AWS risorse, come le configurazioni VPC, oppure includono una restrizione che deve essere applicata all'intero ambiente. Per la maggior parte, il team cloud apporta modifiche manuali una tantum, come l'aggiunta o l'aggiornamento di una policy.
Dopo che l'organizzazione ha utilizzato un AWS ambiente per un certo periodo di tempo, è possibile che si stia sviluppando una serie di anti-pattern. Un *anti-pattern* è una soluzione utilizzata frequentemente per un problema ricorrente in cui la soluzione è controproducente, inefficace o meno efficace di un'alternativa. In alternativa a questi anti-pattern, l'organizzazione può utilizzare restrizioni a livello di ambiente più efficaci, come le policy di controllo dei AWS Organizations servizi () o i set di autorizzazioni di IAM Identity Center. SCPs SCPs e i set di autorizzazioni possono fornire restrizioni aggiuntive per i tipi di risorse, ad esempio impedire agli utenti di configurare un bucket Amazon Simple Storage Service (Amazon S3) pubblico. Sebbene si possa essere tentati di limitare ogni possibile configurazione di sicurezza, esistono limiti alle dimensioni delle policy e ai set di autorizzazioni. SCPs Consigliamo un approccio equilibrato ai controlli preventivi e investigativi.
Di seguito sono riportati alcuni controlli dello standard AWS Security Hub CSPM [Foundational Security Best Practices (FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) di cui il team cloud potrebbe essere responsabile:
+ [[EC2.2] Il gruppo di sicurezza predefinito VPC non dovrebbe consentire il traffico in entrata e in uscita](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2)
+ [[EC2.6] La registrazione del flusso VPC deve essere abilitata in tutti i casi VPCs](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-6)
+ [[EC2.23] I gateway di transito Amazon EC2 non devono accettare automaticamente le richieste di allegati VPC](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-23)
+ [[CloudTrail.1] CloudTrail deve essere abilitato e configurato con almeno un percorso multiregionale che includa eventi di gestione di lettura e scrittura](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudtrail-controls.html#cloudtrail-1)
+ [[Config.1] AWS Config dovrebbe essere abilitato](https://docs.aws.amazon.com/securityhub/latest/userguide/config-controls.html#config-1)
Per questo esempio, il team cloud sta esaminando una scoperta relativa al controllo FSBP EC2.2. La [documentazione relativa](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2) a questo controllo consiglia di non utilizzare il gruppo di sicurezza predefinito perché consente un ampio accesso tramite le regole predefinite in entrata e in uscita. Poiché il gruppo di sicurezza predefinito non può essere eliminato, si consiglia di modificare le impostazioni delle regole per limitare il traffico in entrata e in uscita. Per risolvere questo problema in modo efficiente, il team cloud dovrebbe utilizzare meccanismi consolidati per modificare le regole del gruppo di sicurezza per tutti, VPCs poiché ogni VPC ha questo gruppo di sicurezza predefinito. Nella maggior parte dei casi, i team cloud gestiscono le configurazioni VPC utilizzando [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)personalizzazioni o uno strumento Infrastructure as Code (IaC), come o. [https://www.terraform.io/](https://www.terraform.io/)
# Esempio di team applicativo: creazione di una regola AWS Config
Di seguito sono riportati alcuni controlli dello standard di sicurezza Security Hub CSPM [Foundational Security Best Practices (FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) di cui l'applicazione o il team di sviluppo potrebbero essere responsabili:
+ [[CloudFront.1] le CloudFront distribuzioni devono avere un oggetto root predefinito configurato](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudfront-controls.html#cloudfront-1)
+ [[EC2.19] I gruppi di sicurezza non dovrebbero consentire l'accesso illimitato alle porte ad alto rischio](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19)
+ [[CodeBuild.1] CodeBuild GitHub o il repository sorgente di Bitbucket dovrebbero usare URLs OAuth](https://docs.aws.amazon.com/securityhub/latest/userguide/codebuild-controls.html#codebuild-1)
+ [[ECS.4] I contenitori ECS devono essere eseguiti come non privilegiati](https://docs.aws.amazon.com/securityhub/latest/userguide/ecs-controls.html#ecs-4)
+ [[ELB.1] Application Load Balancer deve essere configurato per reindirizzare tutte le richieste HTTP a HTTPS](https://docs.aws.amazon.com/securityhub/latest/userguide/elb-controls.html#elb-1)
Per questo esempio, il team dell'applicazione sta esaminando una scoperta relativa al controllo FSBP EC2.19. Questo controllo verifica se il traffico in entrata senza restrizioni per i gruppi di sicurezza è accessibile alle porte specificate che presentano il rischio più elevato. Questo controllo ha esito negativo se una qualsiasi delle regole di un gruppo di sicurezza consente il traffico in ingresso da `0.0.0.0/0` o `::/0` verso tali porte. La [documentazione relativa](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19) a questo controllo consiglia di eliminare le regole che consentono questo traffico.
Oltre ad affrontare la regola del singolo gruppo di sicurezza, questo è un ottimo esempio di scoperta che dovrebbe portare a una nuova AWS Config [regola](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html). Utilizzando la [modalità di valutazione proattiva](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config-rules.html#aws-config-rules-evaluation-modes), puoi contribuire a prevenire l'implementazione di regole rischiose per i gruppi di sicurezza in futuro. La modalità proattiva valuta le risorse prima che vengano distribuite in modo da evitare configurazioni errate delle risorse e i relativi problemi di sicurezza. Quando implementano un nuovo servizio o una nuova funzionalità, i team applicativi possono eseguire le regole in modalità proattiva nell'ambito della loro pipeline di integrazione e distribuzione continua (CI/CD) per identificare le risorse non conformi. L'immagine seguente mostra come utilizzare una AWS Config regola proattiva per confermare la conformità dell'infrastruttura definita in un modello. AWS CloudFormation
![\[Una AWS Config regola proattiva che verifica la conformità di un modello AWS CloudFormation\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/vulnerability-management/images/cloudformation-config-proactive-workflow.png)
In questo esempio è possibile ottenere un'altra importante efficienza. Quando un team applicativo crea una AWS Config regola proattiva, può condividerla in un archivio di codice comune in modo che altri team applicativi possano utilizzarla.
Ogni risultato associato a un controllo CSPM di Security Hub contiene dettagli sulla scoperta e un collegamento alle istruzioni per risolvere il problema. Sebbene i team addetti al cloud possano riscontrare risultati che richiedono una correzione manuale e una tantum, se del caso, consigliamo di creare controlli proattivi che identifichino i problemi il prima possibile nel processo di sviluppo.