Gobernanza de AWS WAF a escala

Las grandes organizaciones, con múltiples equipos que desarrollan y operan sus propias aplicaciones web o API, emplean herramientas y procesos para impulsar la coherencia de los controles de seguridad en todos los equipos, a fin de evitar puntos de conexión expuestos con protecciones débiles o inexistentes. AWS Firewall Manager es una herramienta que las organizaciones pueden utilizar para controlar las implementaciones de AWS WAF y Shield Avanzado a escala.

Firewall Manager le permite definir políticas de AWS WAF o Shield Avanzado que se implementan automáticamente en los recursos expuestos públicamente, como distribuciones de CloudFront, ALB o API Gateway. Una política consta de los siguientes elementos:

• Un ámbito que defina dónde se aplica. ¿Qué tipo de recursos (CloudFront, ALB, etc.)? ¿Incluye o excluye recursos con etiquetas específicas? ¿Qué cuentas o unidades organizativas se incluyen o excluyen?
• Reglas que definen a qué grupos de reglas de WAF se aplicar, si se habilita el registro de forma centralizada y si se agregan protecciones de Shield Avanzado.
• Una acción que define qué hacer cuando se encuentra un recurso dentro del ámbito de una política. Por ejemplo, puede aplicar automáticamente las reglas de la política o simplemente informar de ello. En una implementación inicial de Firewall Manager, se recomienda empezar sin corrección automática, para identificar los recursos que requieren una administración manual con un impacto mínimo en las aplicaciones existentes. Cuando se alcance un nivel de confianza superior, puede cambiar Firewall Manager a la corrección automática.

Para utilizar Firewall Manager, tenga en cuenta primero sus requisitos previos. Tenga en cuenta que AWS Config es uno de los requisitos previos de Firewall Manager. Para optimizar el costo de AWS Config, si solo está habilitado para usar Firewall Manager, limite los tipos de recursos para registrar la configuración a los recursos relevantes para su escenario (por ejemplo, WAF, distribuciones de CloudFront, equilibradores de carga, etc.). Tenga en cuenta también que las políticas son estructuras regionales (por ejemplo, necesita una política global para CloudFront y una política regional en cada región en la que tenga recursos regionales como ALB y API Gateway). Considere esta solución de AWS para facilitar la implementación de políticas de Firewall Manager en todas las AWS Organizations

Cuando crea una política WAF, Firewall Manager implementa una ACL web de WAF con las reglas de WAF que contiene la política en las cuentas de AWS dentro del ámbito de la política. En una política de WAF, puede definir dos tipos de grupos de reglas que Firewall Manager agregará a la ACL web implementada:

• Un primer grupo de reglas, que se evaluará antes que cualquier otra regla.
• Un último grupo de reglas, que se evaluará al final.

Esto le permite dar al equipo de seguridad central la posibilidad de administrar grupos de reglas comunes en toda su organización, mientras que da a sus equipos de aplicaciones la posibilidad de agregar reglas personalizadas relevantes para su aplicación, entre el primer y el último grupo de reglas comunes. Dado que las reglas de AWS WAF se evalúan por orden, el primer grupo de reglas comunes se evalúa antes que cualquier otra regla, seguido de las reglas creadas por los equipos de aplicaciones y, por último, el último grupo de reglas comunes.

Puede crear una canalización CI/CD para actualizar los grupos de reglas comunes de WAF de la política de AWS WAF en la cuenta administrativa de AWS, que, a continuación, Firewall Manager implementa en toda su organización en cuestión de minutos. Descubra en este blog cómo OLX implementó una política de WAF central mediante una canalización CI/CD, con un sistema de registro central.

Firewall Manager es una herramienta flexible que le permite establecer diversas estrategias de gobernanza de la seguridad en función de los requisitos de su organización. En cualquier gobernanza de seguridad centralizada, debe hacer un balance entre cuánto aplica las reglas de forma centralizada para aumentar los niveles de protección, frente a cuánto quiere gestionar los falsos positivos causados por reglas comunes implementadas de forma centralizada.

Si dispone de equipos de aplicaciones muy autónomos y desea evitar la gestión de falsos positivos, cree una única política de WAF central que aborde las amenazas críticas. Por ejemplo, puede crear reglas de WAF basadas en límites de tasas con umbrales altos, combinadas con listas de reputación de IP maliciosas de alta confianza y reglas de bloqueo geográfico para países embargados. También puede habilitar Shield Avanzado y activar la mitigación automática de ataques DDoS en la capa de aplicaciones. Estas reglas suelen tener muy pocos falsos positivos, pero son eficaces para proteger contra inundaciones HTTP. Además, cuando se descubren vulnerabilidades de Zero Day críticas y de alto impacto, puede aplicar mitigaciones de forma centralizada mediante el grupo de reglas comunes del WAF implementado.

Se recomienda crear una wiki interna para los equipos de sus aplicaciones, con orientación sobre las prácticas recomendadas para agregar reglas de WAF personalizadas en su ACL web, que sean relevantes para su aplicación. Por ejemplo, guíelos para que agreguen protecciones contra ataques SQLi y XSS si su aplicación es vulnerable a tales ataques.

Si quiere aumentar su cobertura de seguridad central a una gama más amplia de amenazas, refuerce sus grupos de reglas comunes centrales, pero dé a los equipos de aplicaciones la posibilidad de gestionar los falsos positivos de forma autónoma. Para implementar este modelo de gobernanza de WAF, ponga sus reglas comunes en el primer grupo de reglas de la política de WAF en modo de recuento. Estas reglas solo emitirán etiquetas, que podrá utilizar en el último grupo de reglas de la política de WAF para bloquear las peticiones que coincidan con estas etiquetas.

Si los equipos de aplicaciones encuentran falsos positivos, pueden crear reglas de exclusión con las etiquetas emitidas por las reglas. Para ilustrarlo con un ejemplo, considere el escenario en el que se agregan reglas administradas de Amazon (AMR) para la protección contra SQLi en modo de recuento al primer grupo de reglas. En el último grupo de reglas, una regla bloquea las solicitudes con la etiqueta label_matched=”SQLi_BODY” emitida por las AMR mencionadas anteriormente. Si las AMR presentan un falso positivo a una aplicación en una URL específica (url=”/form1”), el equipo de aplicaciones puede crear una regla de exclusión en la ACL web que mitigue este falso positivo (por ejemplo, IF url=”/form1” AND label_matched=”SQLi_BODY” then ALLOW). La acción de la regla ALLOW es terminante, lo que significa que AWS WAF dejará de evaluar las reglas de bloqueo posteriores.

Para implementar cambios en esta política sin afectar a las aplicaciones existentes, considere la posibilidad de crear una réplica de esta política para que los equipos de aplicaciones la utilicen en entornos de ensayo. Ambas políticas deben tener ámbitos mutuamente excluyentes. Por ejemplo, la política de producción se aplica a todas las distribuciones de CloudFront excepto a aquellas con la etiqueta de ensayo y la política de ensayo, a todas las distribuciones de CloudFront con la etiqueta de ensayo. Para la mayoría de las actualizaciones, puede implementarlas primero en la política de ensayo y notificarlas a todos los equipos de aplicaciones mediante un tema de SNS. Una vez notificado el cambio, los equipos de aplicaciones prueban la nueva versión de la política en su entorno de ensayo, lo que puede automatizarse, y gestionan los falsos positivos si es necesario. A continuación, y tras un plazo acordado, el equipo central propaga el cambio a la política de producción. Las actualizaciones críticas que no pueden tardar una semana, como las protecciones contra Log4j CVE, pueden aplicarse inmediatamente a expensas de algunos falsos positivos temporales, hasta que los equipos de aplicaciones gestionen las excepciones.

Si desea aplicar un valor de referencia de seguridad coherente y, al mismo tiempo, permitir cierta personalización por parte de los administradores de cuentas. En este artículo se describen los pasos para diseñar e implementar una política de valor de referencia de seguridad gestionada de forma centralizada. También detalla las prácticas recomendadas para probar e implementar la política.

Si tiene los mismos requisitos que antes, pero quiere reducir la carga cognitiva que supone reforzar la seguridad de las aplicaciones en los equipos de aplicaciones, considere la posibilidad de crear un catálogo de políticas para los distintos tipos de aplicaciones presentes en su organización. Por ejemplo, puede tener un catálogo con dos políticas:

• Primera política: recomendada para proteger aplicaciones basadas en WordPress
• Segunda política: recomendada para proteger aplicaciones PHP con una base de datos SQL. Puede crear dos versiones de esta política, con diferentes niveles de sensibilidad de bloqueo. De esta forma, los equipos de aplicaciones pueden elegir la que se adapte a sus requisitos de seguridad (nivel de paranoia), y a su disposición para gestionar falsos positivos.
  
  

El ámbito de cada política se define mediante una etiqueta específica (por ejemplo, wordpress para la primera política, y LAMP_HIGH/LAMP_LOW para las segundas políticas). Los equipos de aplicaciones consultan el catálogo de políticas disponibles y aplican la etiqueta de la política elegida a sus recursos. Firewall Manager asocia de forma automática las ACL web de WAF a sus recursos.

Tenga en cuenta que, con este enfoque, puede gestionar los falsos positivos y los cambios de etapa de la misma forma descrita en la sección anterior.

En su aplicación, puede utilizar señales personalizadas para identificar comportamientos anormales, en función de lo que se espera de su aplicación. Por ejemplo, es probable que espere que los usuarios naveguen por su aplicación en un orden determinado, o que un usuario haga un pedido de determinados productos desde o hacia determinados países según su dirección registrada. Al utilizar estas señales, puede automatizar su respuesta mediante AWS WAF, por ejemplo, al bloquear o desafiar mediante CAPTCHA las solicitudes procedentes de IP con un comportamiento sospechoso en la aplicación. Para empezar con el concepto de automatización de WAF basado en señales de aplicación considere los ejemplos en esta Solución de AWS.

Las automatizaciones avanzadas incluyen:

• Consumo de eventos de alto riesgo emitidos por Cognito durante el proceso de inicio de sesión o registro.
• Consumo de eventos de alto riesgo identificados por Fraud Detector. Fraud Detector utiliza el machine learning (ML) y 20 años de experiencia en detección de fraudes de Amazon Web Services (AWS) y Amazon.com para identificar automáticamente patrones fraudulentos potenciales hechos por humanos y bots en tiempo real. Fraud Detector permite detectar fraudes mediante el análisis del comportamiento de los usuarios a nivel de aplicación, y utiliza sus propios datos históricos de fraude para entrenar, probar e implementar modelos personalizados de machine learning de detección de fraudes adaptados a su caso de uso.

Si prefiere descargar completamente la administración de WAF de los equipos de aplicaciones a su equipo de seguridad central, cree una política dedicada para cada equipo de aplicaciones, con un ámbito que solo se aplique a sus cuentas de AWS. En este caso, tiene que crear procesos para la configuración inicial y canales de comunicación entre los equipos de aplicaciones y su equipo de seguridad central para operaciones como la gestión de falsos positivos.

• Documento técnico: ejemplos de gobernanza del documento técnico Orientación para la implementación de AWS WAF
• Charla de AWS re:Inforce 2024: Cómo gestiona Twilio las políticas de AWS WAF a escala
• Encuentre socios de entrega de AWS WAF
• Blog : Operating models for Web App Security Governance in AWS