Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Ejemplos de clasificación y corrección de los resultados de seguridad
En esta sección se proporcionan ejemplos del proceso de clasificación para los equipos de seguridad, la nube y aplicaciones. Se analizan los tipos de resultados que suele abordar cada equipo y se proporciona un ejemplo de cómo responder ante ellos. También se incluye una guía de corrección de alto nivel.
**Topics**
+ [Ejemplo de equipo de seguridad: creación de una regla de automatización CSPM de Security Hub](security-team-example.md)
+ [Ejemplo del equipo de la nube: cambio de configuraciones de VPC](cloud-team-example.md)
+ [Ejemplo del equipo de aplicaciones: creación de una regla AWS Config](application-team-example.md)
# Ejemplo de equipo de seguridad: creación de una regla de automatización CSPM de Security Hub
El equipo de seguridad recibe las conclusiones relacionadas con la detección de amenazas, incluidas las de Amazon GuardDuty . Para obtener una lista completa de los tipos de GuardDuty búsqueda clasificados por tipo de AWS recurso, consulte [Búsqueda de tipos](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) en la GuardDuty documentación. Los equipos de seguridad deben estar familiarizados con todos estos tipos de resultados.
Para este ejemplo, el equipo de seguridad acepta el nivel de riesgo asociado a los hallazgos de seguridad en un Cuenta de AWS documento que se utiliza estrictamente con fines de aprendizaje y no incluye datos importantes o confidenciales. El nombre de esta cuenta es `sandbox` y el ID de la cuenta es `123456789012`. El equipo de seguridad puede crear una regla de AWS Security Hub CSPM automatización que suprima todos los GuardDuty hallazgos de esta cuenta. Puede crear una regla a partir de una plantilla, que abarca muchos casos de uso comunes, o puede crear una regla personalizada. En Security Hub CSPM, recomendamos obtener una vista previa de los resultados de los criterios para confirmar que la regla arroja los resultados esperados.
**nota**
En este ejemplo, se destaca la funcionalidad de las reglas de automatización. No recomendamos suprimir todos los GuardDuty resultados de una cuenta. El contexto es importante, y cada organización debe elegir qué resultados suprimir en función del tipo de datos, la clasificación y los controles de mitigación.
A continuación, se incluyen los parámetros que se utilizan para crear esta regla de automatización:
+ **Regla:**
+ El **nombre de la regla** es `Suppress findings from Sandbox account`.
+ La **descripción de la regla** es `Date: 06/25/23 Authored by: John Doe Reason: Suppress GuardDuty findings from the sandbox account`.
+ **Criterios:**
+ `AwsAccountId` = `123456789012`
+ `ProductName` = `GuardDuty`
+ `WorkflowStatus` = `NEW`
+ `RecordState` = `ACTIVE`
+ **Acción automatizada:**
+ `Workflow.status` es `SUPPRESSED`
Para obtener más información, consulte [Reglas de automatización](https://docs.aws.amazon.com/securityhub/latest/userguide/automation-rules.html) en la documentación de Security Hub CSPM. Los equipos de seguridad disponen de muchas opciones para investigar y corregir los resultados relacionados con las amenazas detectadas. Para obtener más información, consulte [Guía sobre Respuesta ante incidentes de seguridad de AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html). Recomendamos consultar esta guía para confirmar que haya establecido procesos sólidos de respuesta ante incidentes.
# Ejemplo del equipo de la nube: cambio de configuraciones de VPC
El equipo de la nube es responsable de clasificar y corregir los hallazgos de seguridad que tienen tendencias comunes, como los cambios en la configuración AWS predeterminada que podrían no adaptarse a su caso de uso. Estos hallazgos suelen afectar a muchos Cuentas de AWS recursos, como las configuraciones de VPC, o incluyen una restricción que debería aplicarse a todo el entorno. En su mayor parte, el equipo de la nube hace cambios manuales y puntuales, como agregar o actualizar una política.
Una vez que su organización haya utilizado un AWS entorno durante algún tiempo, es posible que se esté desarrollando un conjunto de antipatrones. Un *antipatrón* es una solución que se utiliza con frecuencia para un problema recurrente en el que la solución es contraproducente, ineficaz o menos eficaz que una alternativa. Como alternativa a estos antipatrones, su organización puede utilizar restricciones que afecten a todo el entorno y que sean más eficaces, como las políticas de control de AWS Organizations servicios (SCPs) o los conjuntos de permisos del IAM Identity Center. SCPs y los conjuntos de permisos pueden proporcionar restricciones adicionales para los tipos de recursos, como impedir que los usuarios configuren un bucket público de Amazon Simple Storage Service (Amazon S3). Aunque puede resultar tentador restringir todas las configuraciones de seguridad posibles, las políticas tienen límites de tamaño SCPs y conjuntos de permisos. Recomendamos un enfoque equilibrado de los controles preventivos y de detección.
Los siguientes son algunos controles del estándar de [mejores prácticas de seguridad AWS Security Hub CSPM fundamentales (FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) de los que podría ser responsable el equipo de la nube:
+ [[EC2.2] El grupo de seguridad predeterminado de la VPC no debe permitir el tráfico entrante ni saliente](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2)
+ [[EC2.6] El registro de flujo de VPC debe estar habilitado en todos VPCs](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-6)
+ [[EC2.23] Amazon EC2 Transit Gateways no debe aceptar automáticamente las solicitudes de adjuntos de VPC](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-23)
+ [[CloudTrail.1] CloudTrail debe habilitarse y configurarse con al menos un registro multirregional que incluya eventos de administración de lectura y escritura](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudtrail-controls.html#cloudtrail-1)
+ [[Config.1] AWS Config debe estar activado](https://docs.aws.amazon.com/securityhub/latest/userguide/config-controls.html#config-1)
Para este ejemplo, el equipo de la nube aborda un resultado relativo al control EC2.2 de FSBP. En la [documentación](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2) de este control se recomienda no utilizar el grupo de seguridad predeterminado, ya que permite un amplio acceso mediante las reglas de entrada y salida predeterminadas. Dado que el grupo de seguridad predeterminado no se puede eliminar, se recomienda cambiar la configuración de reglas para restringir el tráfico entrante y saliente. Para abordar este problema de manera eficiente, el equipo de nube debe usar los mecanismos establecidos para modificar las reglas de los grupos de seguridad para todos, VPCs ya que cada VPC tiene este grupo de seguridad predeterminado. En la mayoría de los casos, los equipos de la nube administran las configuraciones de VPC mediante personalizaciones de [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) o una herramienta de infraestructura como código (IaC), como [https://www.terraform.io/](https://www.terraform.io/) o [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html).
# Ejemplo del equipo de aplicaciones: creación de una regla AWS Config
Los siguientes son algunos controles del estándar de seguridad Security Hub CSPM [Foundational Security Best Practices (FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) de los que podría ser responsable la aplicación o el equipo de desarrollo:
+ [[CloudFront.1] las CloudFront distribuciones deben tener configurado un objeto raíz predeterminado](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudfront-controls.html#cloudfront-1)
+ [[EC2.19] Los grupos de seguridad no deben permitir el acceso ilimitado a los puertos de alto riesgo](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19)
+ [[CodeBuild.1] CodeBuild GitHub o el repositorio fuente de Bitbucket deberían usar URLs OAuth](https://docs.aws.amazon.com/securityhub/latest/userguide/codebuild-controls.html#codebuild-1)
+ [[ECS.4] Los contenedores de ECS deben ejecutarse sin privilegios](https://docs.aws.amazon.com/securityhub/latest/userguide/ecs-controls.html#ecs-4)
+ [[ELB.1] Application Load Balancer debe configurarse para redirigir todas las solicitudes HTTP a HTTPS](https://docs.aws.amazon.com/securityhub/latest/userguide/elb-controls.html#elb-1)
Para este ejemplo, el equipo de aplicaciones aborda un resultado relativo al control EC2.19 de FSBP. Este control comprueba si el tráfico entrante ilimitado de los grupos de seguridad es accesible para los puertos especificados que tienen el mayor riesgo. Este control falla si alguna de las reglas de un grupo de seguridad permite la entrada de tráfico desde `0.0.0.0/0` o `::/0` para esos puertos. En la [documentación](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19) de este control se recomienda eliminar las reglas que permiten este tráfico.
[Además de abordar la regla del grupo de seguridad individual, este es un excelente ejemplo de un hallazgo que debería dar como resultado una nueva regla. AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) Al utilizar el [modo de evaluación proactiva](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config-rules.html#aws-config-rules-evaluation-modes), puede ayudar a evitar la implementación de reglas de grupos de seguridad de riesgo en el futuro. El modo proactivo evalúa los recursos antes de que se implementen para evitar los recursos mal configurados y los resultados de seguridad asociados a ellos. Al implementar un nuevo servicio o una nueva funcionalidad, los equipos de aplicaciones pueden ejecutar reglas en modo proactivo como parte de su canalización de integración y entrega continuas (CI/CD) para identificar los recursos que no cumplen con los requisitos. La siguiente imagen muestra cómo puede utilizar una AWS Config regla proactiva para confirmar que la infraestructura definida en una AWS CloudFormation plantilla es compatible.
![\[Una AWS Config regla proactiva que comprueba el cumplimiento AWS CloudFormation de una plantilla\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/vulnerability-management/images/cloudformation-config-proactive-workflow.png)
En este ejemplo se puede obtener otra eficiencia importante. Cuando un equipo de aplicaciones crea una AWS Config regla proactiva, puede compartirla en un repositorio de código común para que otros equipos de aplicaciones puedan usarla.
Cada hallazgo asociado a un control CSPM de Security Hub contiene detalles sobre el hallazgo y un enlace a las instrucciones para solucionar el problema. Si bien los equipos de la nube pueden encontrar resultados que requieran una corrección manual y puntual, cuando proceda, recomendamos crear controles proactivos que identifiquen los problemas lo antes posible en el proceso de desarrollo.