Seguridad de redes

La seguridad de red protege las cargas de trabajo en la nube frente a amenazas como el acceso no autorizado, las infracciones de datos y la interrupción del servicio mediante el control del tráfico en varios límites. A diferencia de las defensas tradicionales centradas en el perímetro, los entornos de nube modernos exigen estrategias de defensa en profundidad con segmentación, conectividad privada y protección perimetral para abordar las superficies de ataque dinámicas, incluidos los servicios expuestos, las rutas de desplazamiento lateral y los canales de comando y control. Las organizaciones que implementan controles de red completos mantienen entornos seguros de forma predeterminada, mientras que aquellos que descuiden estos controles se enfrentan a un movimiento lateral sin restricciones y exposición prolongada a amenazas.

Estos son los tres pilares básicos del dominio de seguridad de red.

Límites de red seguros: Aplique controles estrictos en los bordes de red y entre segmentos a través de la defensa en profundidad que incorpora firewalls, protección contra DDoS, firewalls de aplicaciones web y conectividad privada, siguiendo el principio de privilegios mínimos para denegar el tráfico no autorizado de forma predeterminada.

Controles relacionados:

• NS-2: Protección de servicios en la nube con controles de red
• NS-3: Implementación del firewall en el perímetro de la red empresarial
• NS-5: Implementación de la protección contra DDOS
• NS-6: Implementación del firewall de aplicaciones web
• NS-9: conexión de red local o en la nube de forma privada

Aplicar aislamiento de red: Divida las redes en segmentos aislados alineados con la estrategia de segmentación empresarial y los niveles de riesgo para limitar la propagación de amenazas, reducir la superficie expuesta a ataques y evitar el movimiento lateral no autorizado.

Controles relacionados:

• NS-1: Establecer límites de segmentación de red

Supervisión y respuesta: Mantenga la visibilidad continua de la actividad de red a través de una supervisión completa, detección de intrusiones y seguridad de protocolo para identificar rápidamente comportamientos sospechosos, infracciones de directivas y amenazas activas.

Controles relacionados:

• NS-4: Implementación de sistemas de detección de intrusiones/prevención de intrusiones (IDS/IPS)
• NS-8: Detección y deshabilitación de protocolos y servicios no seguros
• NS-10: Garantizar la seguridad del sistema de nombres de dominio (DNS)

NS-1: Establecer límites de segmentación de red

Azure Policy: Consulte Definiciones de directivas integradas de Azure: NS-1.

Principio de seguridad

La segmentación de red implica dividir una red en segmentos más pequeños y aislados para controlar y limitar el flujo de tráfico entre los recursos en la nube para reducir el radio de explosión.

Diseñe la segmentación de red para asegurarse de que la implementación de la red virtual se alinea con la estrategia de segmentación empresarial y los distintos niveles de riesgo. La estrategia de segmentación común incluye:

• Separar la red corporativa utilizando redes de aplicaciones
• Redes de aplicaciones independientes
• Redes independientes del entorno de producción y pruebas

Consulte Azure Well-Architected Framework para más información sobre las estrategias clave para la segmentación de red:

• Estrategia de segmentación de Azure

Riesgo para mitigar

Sin límites de segmentación de red, las organizaciones se enfrentan al movimiento lateral sin restricciones, lo que permite a los atacantes atravesar infraestructuras de red y poner en peligro los recursos de alto valor.

• Exposición de red plana: La ausencia de segmentación permite el movimiento lateral sin restricciones, lo que permite a los adversarios poner en peligro los recursos de alto valor mediante el recorrido de una topología de red sin particiones.
• Rutas de escalación de privilegios: Los límites inadecuados permiten vectores de acceso no autorizados, lo que facilita la elevación de privilegios de usuario a través del acceso a subredes y cargas de trabajo confidenciales.
• Propagación de malware: La segmentación insuficiente permite la propagación rápida de código malintencionado, como ransomware en nodos interconectados, amplificando la superficie expuesta a ataques y el impacto operativo.
• Ceguera del tráfico este-oeste: El tráfico entre segmentos sin restricciones dificulta la detección de anomalías y la respuesta a incidentes, lo que reduce la visibilidad de los movimientos internos de amenazas y complica el análisis forense.

MITRE ATT&CK

• Acceso inicial (TA0001): acceso no autorizado a redes y servicios expuestos (por ejemplo, T1190 - explotar aplicación expuesta al público).
• Movimiento lateral (TA0008): ataque pivotante por redes virtuales y tráfico entre subredes no restringido (por ejemplo, T1021 - Servicios remotos).
• Filtración (TA0010): filtración de datos por tráfico saliente no restringido para transferencias de datos no autorizadas a servidores externos (por ejemplo, T1041 - Filtración a través del canal C2).
• Comando y control (TA0011): propagación de malware mediante comunicación con direcciones IP o dominios malintencionados a través de reglas de firewall e inteligencia sobre amenazas (por ejemplo, T1071 - Protocolo de capa de aplicación).

NS-1.1: Creación de la segmentación mediante redes virtuales y subredes

El aislamiento de red virtual establece límites de seguridad fundamentales dentro de entornos de nube, lo que permite a las organizaciones separar las cargas de trabajo por nivel de confianza, unidad organizativa o agrupación de aplicaciones. Este enfoque evita el movimiento lateral sin restricciones y reduce el radio de explosión cuando se producen infracciones, alineando la arquitectura de red con estrategias de segmentación empresarial y principios de confianza cero.

Implemente la segmentación de red virtual mediante la creación de límites de red aislados y subdivisiones:

• Diseñar topología de red virtual basada en la estrategia de segmentación: Cree redes virtuales alineadas con zonas de confianza, unidades organizativas o agrupaciones de aplicaciones definidas en la estrategia de segmentación empresarial, lo que garantiza que cada red virtual represente un límite de seguridad distinto.

• Aislar cargas de trabajo de alto riesgo: Identifique las cargas de trabajo que requieren aislamiento estricto (por ejemplo, bases de datos de producción, sistemas de procesamiento de pagos) e impleméntelas en redes virtuales aisladas dedicadas para minimizar la exposición y evitar la contaminación cruzada.

• Cree subredes para la segmentación pormenorizadas: Dentro de cada red virtual, cree subredes distintas no superpuestas para segmentar aún más la red en función de los niveles de aplicación (por ejemplo, el nivel web, el nivel de aplicación, el nivel de base de datos) o los requisitos funcionales, lo que permite un control de tráfico y microsegmentación más precisos.

NS-1.2: Restricción del tráfico de red mediante NSG

Los grupos de seguridad de red aplican el filtrado de tráfico en el nivel de interfaz de red y subred, lo que permite un control preciso sobre los flujos de comunicación entre segmentos de red y redes externas. Al implementar directivas de denegación por defecto con reglas de permiso explícitas, las organizaciones garantizan que solo el tráfico autorizado atraviesa los límites de red, evitando el acceso no autorizado y reduciendo la superficie expuesta a ataques.

Implemente la restricción de tráfico de red mediante reglas de NSG:

• Identificar los requisitos de comunicación: Analice los recursos de cada red virtual para comprender sus necesidades de comunicación de tráfico norte-sur (externo) y este-oeste (interno), documentar los puertos necesarios, los protocolos, las direcciones de origen y las direcciones de destino para las funciones empresariales legítimas.

• Definir reglas de permiso y denegación explícitas: Para las aplicaciones bien definidas (por ejemplo, arquitecturas de tres niveles), use el enfoque "denegar de forma predeterminada, permitir por excepción" para crear reglas de NSG basadas en el puerto, el protocolo, la dirección IP de origen y la dirección IP de destino, lo que permite explícitamente solo el tráfico necesario al denegar todas las demás comunicaciones.

• Use grupos de seguridad de aplicaciones para escenarios complejos: Cuando muchas aplicaciones y puntos de conexión interactúan, simplifique la administración de reglas de NSG mediante grupos de seguridad de aplicaciones (ASG) para agrupar recursos lógicamente (por ejemplo, servidores web, servidores de bases de datos), defina reglas de NSG basadas en estos grupos en lugar de direcciones IP explícitas, lo que mejora la capacidad de mantenimiento y reduce la complejidad de la configuración.

• Supervisión y optimización con registros de flujo: Habilite el registro de flujo de red virtual para supervisar el tráfico permitido o denegado por las reglas de NSG, identificando el tráfico denegado con frecuencia que puede indicar una configuración incorrecta o tráfico permitido con frecuencia que podría informar a la optimización de reglas y reducir el ruido de registro.

Ejemplo de implementación

Una organización necesitaba proteger una aplicación de varios niveles con entornos de producción, desarrollo y pruebas independientes, a la vez que impedía el movimiento lateral no autorizado y el acceso externo.

Desafiar: La organización tenía una aplicación de tres niveles (web, aplicación, base de datos) con todos los recursos en un único segmento de red grande, lo que permite la comunicación sin restricciones entre todos los niveles y entornos. Esto creó riesgos de seguridad significativos, incluido el posible movimiento lateral entre producción y no producción, acceso a Internet sin restricciones desde servidores de bases de datos y incapacidad para aislar cargas de trabajo de alto riesgo.

Enfoque de solución:

• Segmentación de red virtual por entorno: Se crearon redes virtuales independientes para producción (10.0.0.0/16), desarrollo (10.1.0.0/16) y pruebas (10.2.0.0/16), establecimiento de límites de aislamiento de red que impiden el acceso entre entornos y limitan el radio de explosión de posibles infracciones.
• Segmentación de subred por nivel: Dentro de la red virtual de producción, creó distintas subredes no superpuestas para cada nivel de aplicación: nivel web (10.0.1.0/24), nivel de aplicación (10.0.2.0/24) y nivel de base de datos (10.0.3.0/24): habilitación del control de tráfico granular entre niveles.
• Reglas del grupo de seguridad de red para el control de tráfico norte-sur: Reglas de grupo de seguridad de red configuradas para denegar todo el tráfico entrante de Internet (0.0.0.0/0) a subredes internas y restringir el acceso saliente a Internet solo a destinos de confianza, con reglas específicas que permiten solo las conexiones externas necesarias para el nivel web al bloquear todo el acceso a Internet desde el nivel de base de datos.
• Reglas de NSG para el control de tráfico este-oeste: Se han implementado directivas de denegación por defecto con reglas de permiso explícitas entre niveles: el nivel web permite la salida saliente al nivel de aplicación solo en los puertos necesarios, el nivel de aplicación solo permite la salida al nivel de base de datos en el puerto 1433 (SQL) y el nivel de base de datos deniega todo el tráfico entrante excepto desde la subred del nivel de aplicación.
• Acceso de administración remota: Puertos de administración remota restringidos (RDP 3389/TCP, SSH 22/TCP) para aceptar conexiones solo desde la subred del host bastión de confianza (10.0.0.0.0/26), lo que elimina el acceso directo a Internet a las interfaces de administración.

Resultado: La organización eliminó el movimiento lateral sin restricciones entre los niveles de aplicación y los entornos, redujo significativamente la superficie expuesta a ataques mediante la eliminación del acceso directo a Internet de los sistemas back-end y estableció límites de red ejecutables alineados con principios de confianza cero. Los registros de flujo habilitaron la supervisión continua del tráfico permitido y denegado para la optimización continua y la validación de la posición de seguridad.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

• NIST SP 800-53 Rev.5: SC-7, SC-32, AC-4, CM-7
• PCI-DSS v4: 1.2.1, 1.3.1, 1.4.1
• Cis Controls v8.1: 12.1, 12.2, 12.6
• NIST CSF v2.0: PR. IR-01, PR. AC-05
• ISO 27001:2022: A.8.20, A.8.21
• SOC 2: CC6.1, CC6.6

NS-2: Protección de servicios nativos en la nube con controles de red

Azure Policy: Consulte Definiciones de directivas integradas de Azure: NS-2.

Principio de seguridad

Use características nativas de servicio para proteger el acceso de red a los recursos para evitar y reducir la exposición de los recursos a la red que no es de confianza. Estas características incluyen:

• Establezca puntos de acceso privados para que los recursos eviten la exposición del tráfico de red que atraviesa la red pública.
• Implemente el recurso en redes virtuales, donde puede restringir la red virtual para establecer un punto de acceso privado para el servicio.
• Configure firewalls nativos de servicio para restringir el tráfico entrante o deshabilitar el acceso a la red pública.

Nota: Además del control básico de acceso a la red y el filtrado de tráfico, también debe usar funcionalidades de detección de amenazas para supervisar servicios como DNS (NS-10) para detectar la posible filtración de datos.

Riesgo para mitigar

Los actores de amenazas aprovechan los servicios en la nube expuestos públicamente para llevar a cabo la filtración de datos, los ataques de capa de aplicación y la interceptación del tráfico.

• Filtración de datos a través de puntos de conexión públicos: Los atacantes aprovechan las cuentas de almacenamiento, las bases de datos o las API de acceso público para filtrar datos confidenciales mediante el establecimiento de conexiones no autorizadas a puntos de conexión expuestos, pasando los controles de segmentación de red y habilitando el robo de datos a gran escala.
• Ataques a nivel de aplicación contra puntos de acceso públicos: Los ataques de denegación de servicio distribuido (DDoS), la inyección SQL y otros exploits de aplicaciones tienen como objetivo servicios web, API y bases de datos expuestos públicamente, sobrecargando recursos o explotando vulnerabilidades para provocar interrupciones del servicio o comprometer los datos.
• Ataques de tipo "man in the middle": Los atacantes interceptan el tráfico que fluye a través de redes públicas a servicios expuestos públicamente, capturando credenciales, tokens de sesión o datos confidenciales transmitidos sin un cifrado adecuado o conectividad privada, lo que permite la adquisición de cuentas o el robo de datos.

MITRE ATT&CK

• Acceso inicial (TA0001): acceso no autorizado por exposición a Internet de manera pública de servicios en la nube (por ejemplo, servicios de almacenamiento en la nube, servicios de base de datos), explotación de vulnerabilidades dirigidas a endpoints públicos (por ejemplo, T1190 - Exploit de aplicación orientada al público).
• Filtración (TA0010): filtración de datos mediante el enrutamiento del tráfico a través de conexiones de red virtual privadas, lo que reduce el riesgo de pérdida de datos a servidores externos (por ejemplo, T1041 - Filtración a través del canal C2).
• Movimiento lateral (TA0008): el pivoteo de servicios por parte del atacante dentro de redes virtuales, acceso no autorizado entre recursos en la nube (por ejemplo, T1021 - Servicios remotos).

NS-2.1 Uso de Private Link para la conexión de servicio

La conectividad privada elimina la exposición pública a Internet para los servicios en la nube mediante el establecimiento de rutas de acceso de red directas dentro de la infraestructura virtual. Private Link crea puntos de conexión privados con direcciones IP dedicadas dentro de las redes virtuales, lo que garantiza que el tráfico a los servicios en la nube nunca atraviesa la red pública de Internet al tiempo que mantiene los patrones de acceso basados en DNS. Este enfoque reduce significativamente la superficie expuesta a ataques y evita la filtración de datos a través de puntos de conexión accesibles públicamente.

Implemente la conectividad privada para los servicios en la nube mediante estos pasos:

• Implemente puntos de conexión privados para los servicios admitidos: Cree puntos de conexión privados dentro de la red virtual para los recursos de Azure que admiten Private Link (por ejemplo, Azure Storage, Azure SQL Database, Azure Key Vault), estableciendo direcciones IP privadas (por ejemplo, 10.0.2.4) accesibles solo desde la red virtual.

• Configurar zonas DNS privadas: Cree zonas DNS privadas de Azure para anular la resolución DNS pública, asegurando que los nombres de dominio completos (FQDN) como mystorageaccount1.blob.core.windows.net se resuelvan en direcciones IP privadas dentro de tu red virtual (VNet) en lugar de puntos de conexión públicos, garantizando conectividad continua para las aplicaciones que acceden mediante FQDN.

• Deshabilitar el acceso público: Configure las opciones de nivel de servicio para deshabilitar el acceso a la red pública completamente una vez implementados los puntos de conexión privados, lo que garantiza que todos los flujos de tráfico se realicen exclusivamente a través de la conectividad privada sin reserva a los puntos de conexión públicos.

Nota: Algunos servicios de Azure también pueden permitir la comunicación privada a través de la característica de punto de conexión de servicio , aunque se recomienda Azure Private Link para el acceso seguro y privado a los servicios hospedados en la plataforma Azure. En el caso de las implementaciones como los servicios web hospedados en máquinas virtuales de Azure, evite asignar direcciones IP públicas directamente a las máquinas virtuales, a menos que esté fuertemente justificada; en su lugar, use Azure Application Gateway o Azure Load Balancer como front-end para el acceso al servicio.

NS-2.2 Implementación del servicio en la red virtual

La integración de red virtual permite que los servicios en la nube funcionen dentro de los límites de la red privada, estableciendo conectividad directa a los recursos hospedados en la red virtual sin exposición pública a Internet. Al implementar servicios en redes virtuales, las organizaciones obtienen un control pormenorizado sobre el tráfico de red a través de grupos de seguridad y tablas de rutas, a la vez que mantienen el aislamiento del servicio frente a amenazas externas.

Implemente servicios con integración con VNet donde se admita.

• Implementación de servicios en redes virtuales: Para los servicios que admiten la integración de red virtual (por ejemplo, Azure App Service, Azure Functions, Azure Container Instances), configure la implementación en redes virtuales nuevas o existentes, especificando las subredes adecuadas alineadas con la estrategia de segmentación y habilitando la comunicación privada con otros recursos de red virtual.

• Configurar controles de seguridad de red: Aplique reglas de grupo de seguridad de red (NSG) a la subred del servicio para restringir el tráfico entrante y saliente, lo que implementa el acceso con privilegios mínimos al permitir solo la comunicación necesaria a destinos específicos (por ejemplo, subredes de base de datos, puntos de conexión de almacenamiento) al mismo tiempo que se deniega todo el tráfico.

NS-2.3 Configuración del firewall nativo del servicio

Los firewalls de nivel de servicio proporcionan protección en profundidad de defensa al restringir el acceso a la red en el nivel de recurso, complementando los controles de nivel de red con límites de seguridad específicos de la aplicación. Estas funcionalidades nativas de firewall permiten a las organizaciones limitar la exposición a intervalos IP específicos o redes virtuales, al tiempo que deshabilitan completamente el acceso público cuando sea adecuado, lo que reduce la superficie expuesta a ataques sin necesidad de cambios complejos en la topología de red.

Configurar cortafuegos de servicio para restringir el acceso.

• Habilitación de las características del firewall de servicio: Para los servicios que admiten firewalls nativos (por ejemplo, Azure Storage, Azure SQL Database, Azure Key Vault), habilite la funcionalidad de firewall durante la creación de recursos o en los recursos existentes para controlar qué redes pueden acceder al servicio.

• Definir reglas basadas en IP o basadas en red virtual: Configure reglas de firewall para permitir el acceso solo desde intervalos ip públicos específicos (por ejemplo, redes de oficinas corporativas) o subredes de red virtual de Azure específicas, lo que implementa el acceso con privilegios mínimos al denegar todos los demás orígenes.

• Deshabilite el acceso público siempre que sea posible: Cuando los servicios solo requieren acceso desde redes privadas, use la opción de alternancia para deshabilitar completamente el acceso a la red pública, asegurándose de que el servicio no es accesible desde Internet independientemente de las reglas basadas en IP.

NS-2.4 Uso del perímetro de seguridad de red para el aislamiento de recursos paaS

El perímetro de seguridad de red establece un límite de red lógico alrededor de varios recursos paaS, lo que permite la comunicación segura entre servicios dentro de un perímetro de confianza explícito, a la vez que impide la filtración de datos no autorizada. A diferencia de los controles por recurso, el perímetro de seguridad de red proporciona un límite de seguridad unificado que permite la comunicación dentro del perímetro sin reglas de acceso individuales mientras bloquea el acceso externo de forma predeterminada.

Implemente el perímetro de seguridad de red para proteger los recursos de PaaS:

• Cree y asocie recursos: Establezca un perímetro de seguridad de red y agregue recursos paaS admitidos (Azure Storage, SQL Database, Key Vault, Event Hubs, Cosmos DB) a través de asociaciones de recursos, lo que permite la comunicación dentro del perímetro donde los recursos asociados pueden comunicarse libremente.

• Configurar los modos de acceso y las reglas: Comience con el modo de transición para comprender los patrones de acceso antes de realizar la transición al modo aplicado para obtener la máxima protección. Defina reglas de acceso de entrada y salida explícitas mediante direcciones IP, suscripciones o FQDN para controlar el tráfico fuera del perímetro al tiempo que mantiene la posición de denegación predeterminada.

• Habilite la supervisión y la integración de Private Link: Configure los registros de diagnóstico para capturar los intentos de acceso y las infracciones de directivas. El tráfico del punto de conexión privado se permite automáticamente en el perímetro, complementando la conectividad VNet-a-PaaS con controles de exfiltración de datos a nivel perimetral.

Ejemplo de implementación

Una organización necesitaba proteger la base de datos de back-end y los recursos de almacenamiento al tiempo que habilitaba el acceso desde los servicios de aplicación sin exponer recursos a la red pública de Internet.

Desafiar: La organización tenía cuentas de Azure SQL Database y Azure Storage con puntos de conexión públicos predeterminados, lo que hace que sean accesibles desde Internet y crear riesgos significativos de filtración de datos. Los servicios de aplicación se implementaron con direcciones IP públicas y no tenían integración con red virtual, lo que impedía los controles de acceso basados en la red privada. Los firewalls de nivel de servicio no se configuraron, lo que permite el acceso sin restricciones desde cualquier origen una vez que la autenticación se realizó correctamente.

Enfoque de solución:

• Puntos de conexión de Private Link para servicios PaaS: Puntos de conexión privados implementados para Azure SQL Database (IP privada asignada 10.0.2.4) y cuenta de Azure Storage (IP privada asignada 10.0.2.5) dentro de una subred de punto de conexión privado dedicado (10.0.2.0/24), estableciendo conectividad privada que enruta el tráfico a través de la red troncal de Azure sin exposición a Internet.
• Zonas DNS privadas para la resolución de nombres: Se crearon zonas DNS privadas de Azure para invalidar la resolución DNS pública, lo que garantiza que los FQDN de la aplicación (por ejemplo, mysqldb.database.windows.net, mystorageaccount.blob.core.windows.net) se resuelvan en direcciones IP privadas dentro de la red virtual en lugar de puntos de conexión públicos, manteniendo una conectividad sin problemas para las aplicaciones que usan acceso basado en FQDN.
• Integración de red virtual para servicios de aplicaciones: Integración de red virtual configurada para Azure App Service, la implementación de la aplicación en una subred de aplicación (10.0.1.0/24) para habilitar la comunicación directa con puntos de conexión privados sin necesidad de direcciones IP públicas ni enrutamiento de Internet.
• Firewalls nativos del servicio: Se han habilitado firewalls de nivel de servicio en Azure Storage para restringir el acceso a subredes de red virtual específicas (subred de aplicación 10.0.1.0/24) y servicios de Microsoft de confianza, al tiempo que se deshabilita completamente el acceso a la red pública en el nivel de servicio para que Azure SQL Database aplique la conectividad solo privada.
• Reglas de NSG para defensa en profundidad: Se han aplicado reglas de NSG a la subred de la aplicación que permite el tráfico saliente solo a la subred del punto de conexión privado (10.0.2.0/24) en los puertos necesarios (443 para almacenamiento, 1433 para SQL), implementando control de acceso con privilegios mínimos que complementa las protecciones de nivel de servicio.

Resultado: La organización eliminó la exposición pública a Internet para los recursos de back-end, lo que reduce significativamente los riesgos de filtración de datos y la superficie expuesta a ataques. La conectividad privada garantizaba todo el tráfico entre aplicaciones y servicios de datos en la red troncal de Azure sin atravesar la red pública de Internet, mientras que los controles en capas (Private Link, zonas DNS, firewalls de servicio, NSG) proporcionaban protección en profundidad de defensa alineada con principios de confianza cero.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

• NIST SP 800-53 Rev.5: SC-7(4), SC-7(5), AC-4(21)
• PCI-DSS v4: 1.3.1, 1.3.2, 1.4.2
• Cis Controls v8.1: 12.4, 12.7
• NIST CSF v2.0: PR. AC-05, PR. DS-05
• ISO 27001:2022: A.8.20, A.8.22
• SOC 2: CC6.1, CC6.6

NS-3: Implementación de un firewall en el perímetro de la red empresarial

Azure Policy: Consulte Definiciones de directivas integradas de Azure: NS-3.

Principio de seguridad

Use el firewall en el perímetro de red para realizar un filtrado avanzado en el tráfico de red hacia y desde redes externas, como Internet, y entre segmentos de red internos.

Como mínimo, la directiva de firewall debe incluir:

• Bloquear direcciones IP y sitios incorrectos conocidos.
• Restringir protocolos de alto riesgo, como protocolos de administración remota y protocolos de intranet en redes perimetrales para evitar el acceso no autorizado o el movimiento lateral.
• Aplique reglas de aplicación para permitir solo destinos externos aprobados y bloquear sitios no autorizados o de riesgo.

Riesgo para mitigar

Los adversarios aprovechan las vulnerabilidades expuestas a redes públicas o que no son de confianza a través de protocolos accesibles, dominios malintencionados y controles de red débiles.

• Acceso no autorizado a través de protocolos expuestos: Los protocolos accesibles públicamente como RDP (TCP 3389) o SMB (TCP 445) permiten a los atacantes obtener una entrada no autorizada, poniendo en peligro la integridad del sistema a través de vulnerabilidades de seguridad como ataques de fuerza bruta o ataques dirigidos a CVE.
• Malware y phishing a través de dominios o direcciones IP malintencionados: Los dominios y direcciones IP malintencionados facilitan la entrega de malware o las campañas de suplantación de identidad, poniendo en peligro los puntos de conexión y los datos confidenciales a través de ataques de ingeniería social o de comandos.
• Filtración de datos a través del tráfico saliente sin restricciones: La salida no controlada a destinos no aprobados permite a los adversarios exfiltrar datos confidenciales, correr riesgos de brechas y violaciones de cumplimiento a través de canales encubiertos como POST HTTPS.
• Movimiento lateral debido a una segmentación deficiente: La segmentación de red insuficiente permite a los atacantes dinamizar internamente, aprovechando el tráfico entre segmentos (por ejemplo, SMB, Kerberos) para propagarse desde sistemas en peligro.
• Vulnerabilidades de aplicaciones o direcciones URL que no son de confianza: El acceso a direcciones URL y aplicaciones de riesgo o que no son de confianza aumenta la exposición a vulnerabilidades de seguridad, aumentando los riesgos de incidentes y el incumplimiento de los estándares normativos.

MITRE ATT&CK

• Acceso inicial (TA0001): acceso no autorizado a protocolos de alto riesgo (por ejemplo, RDP/TCP 3389, SSH/TCP 22) o dominios malintencionados (por ejemplo, T1190 - Explotar aplicación orientada al público).
• Comando y control (TA0011): malware que se conecta a direcciones IP o dominios malintencionados (por ejemplo, T1071 - Protocolo de capa de aplicación).
• Filtración (TA0010): transferencias de datos no autorizadas a través del tráfico saliente a destinos no aprobados (por ejemplo, T1041 - Filtración a través del canal C2).
• Movimiento lateral (TA0008): impide el movimiento interno a través del tráfico entre segmentos sin filtrar (por ejemplo, SMB/TCP 445, Kerberos/TCP 88) (por ejemplo, T1021 - Servicios remotos).

NS-3.1 Preparación para la implementación de Azure Firewall

La implementación de Azure Firewall requiere una topología de red adecuada que permita la inspección centralizada del tráfico a través de los límites de red. Las arquitecturas hub-and-spoke colocan el firewall en el núcleo de la red, enrutando todo el tráfico de los nodos secundarios a través de un punto de inspección central, mientras que las rutas definidas por el usuario garantizan que el flujo de tráfico siga las rutas deseadas. Esta preparación establece la base para la protección perimetral completa y el filtrado entre segmentos.

Preparación de la infraestructura de red para la implementación de Azure Firewall:

• Configuración de la topología de red virtual en estrella tipo hub-and-spoke: Implemente Azure Firewall en una red virtual de concentrador para administrar y proteger de forma centralizada el tráfico entre varias redes virtuales de radio que hospedan cargas de trabajo de aplicaciones, estableciendo un único punto de cumplimiento para las directivas de seguridad de red.

• Unirse a redes virtuales radiales: Use el emparejamiento de red virtual para conectar cada red virtual de radio a la red virtual del concentrador donde se implementa Azure Firewall, lo que permite la comunicación entre radios a través del centro y mantiene el aislamiento de red.

• Configurar rutas definidas por el usuario (UDR): Cree tablas de rutas que dirijan el tráfico de red desde redes virtuales de radio a través de Azure Firewall en la red central, incluidas las rutas para la salida a Internet (0.0.0.0/0) y, opcionalmente, el tráfico entre radios si la comunicación de radio a radio requiere inspección.

NS-3.2 Implementación de Azure Firewall con directivas adecuadas

Azure Firewall proporciona filtrado de tráfico de la capa de aplicación con seguimiento de estado y administración centralizada de directivas en segmentos de red empresariales. Al combinar reglas de red, reglas de aplicación e inteligencia sobre amenazas, los firewalls inspeccionan los flujos de tráfico en varias capas, mientras que el filtrado de direcciones URL y la inspección de TLS permiten un control granular sobre las comunicaciones HTTP/HTTPS. El diseño adecuado de directivas equilibra los requisitos de seguridad con las necesidades operativas a través de jerarquías de reglas estructuradas y filtrado basado en categorías.

Implemente y configure Azure Firewall con directivas completas:

• Implementación de Azure Firewall en la red virtual del concentrador: Implemente Azure Firewall (nivel Estándar o Premium en función de las características necesarias) en la red virtual del concentrador, asignando ambas direcciones IP públicas para el tráfico enlazado a Internet y las direcciones IP privadas para el enrutamiento interno desde redes virtuales de radio.

• Cree directivas de firewall con reglas de filtrado: Defina directivas de Azure Firewall que contengan reglas de red (filtrado basado en IP/puerto), reglas de aplicación (filtrado basado en FQDN) y reglas de inteligencia sobre amenazas, organización de reglas en recopilaciones basadas en requisitos de seguridad (por ejemplo, permitir servicios críticos para la empresa, bloquear direcciones IP malintencionadas, denegar categorías de riesgo).

• Configure el filtrado de direcciones URL para el tráfico HTTP/HTTPS: Implemente reglas de aplicación basadas en FQDN para permitir o denegar dominios específicos (por ejemplo, permitir *.microsoft.com, denegar *.torrent) y configurar el filtrado basado en categorías para bloquear categorías de sitios web completos (por ejemplo, Pirateo, Redes sociales) al tiempo que permite categorías relacionadas con el trabajo.

• Habilite la inspección de TLS para el filtrado avanzado: Para las implementaciones de nivel Premium, habilite la inspección de TLS mediante la carga de certificados en Azure Key Vault, lo que permite que el firewall descifre, inspeccione y vuelva a cifrar el tráfico HTTPS para un filtrado de direcciones URL más profundo y la detección de amenazas más allá de la inspección basada en SNI.

Ejemplo de implementación

Una organización con varias cargas de trabajo de aplicaciones en diferentes redes virtuales radiales necesitaba una inspección centralizada de seguridad de red para todo el tráfico enlazado a Internet y las comunicaciones entre radios, a la vez que impedía el acceso a dominios malintencionados y categorías de sitios web no autorizados.

Desafiar: La organización tenía cargas de trabajo implementadas en redes virtuales de radio independientes con acceso directo a Internet, creando directivas de seguridad incoherentes e incapacidad para inspeccionar el tráfico de forma centralizada. Cada radio tenía sus propias reglas del NSG, lo que conduce a la desviación de directivas y a las brechas de seguridad. No había visibilidad de las conexiones salientes a dominios potencialmente malintencionados, sin capacidad para bloquear categorías de sitios web de riesgo (medios sociales, uso compartido de archivos) ni inspección del contenido del tráfico HTTPS. El tráfico entre puntos fluyó libremente sin inspección, posibilitando un movimiento lateral tras un compromiso.

Enfoque de solución:

• Topología hub-and-spoke con firewall centralizado: Implementado Azure Firewall Premium en una red virtual de concentrador (10.0.0.0/16) con AzureFirewallSubnet dedicado (10.0.1.0/26, IP privada del firewall 10.0.1.4), estableciendo un único punto de aplicación para toda la inspección del tráfico de red y administración de directivas.
• Emparejamiento de VNet para conectividad de satélite: Se ha usado el emparejamiento de VNet para conectar la red virtual satélite de la aplicación (10.1.0.0/16) y la red virtual satélite de base de datos (10.2.0.0/16) al hub de red virtual, lo que permite el enrutamiento de tráfico central a través del firewall.
• Rutas definidas por el usuario para el direccionamiento del tráfico: Se crearon tablas de rutas en cada red virtual de spokes que redirige todo el tráfico destinado a Internet (0.0.0.0/0) y el tráfico entre spokes a la dirección IP privada de Azure Firewall (10.0.1.4), lo que fuerza toda la salida a través del punto de inspección central.
• Directivas de firewall con filtrado de varias capas: Directivas completas de Azure Firewall que incluyen reglas de red (permitir DNS UDP/53 a Azure DNS, denegar todos los demás protocolos de forma predeterminada), reglas de aplicación (permitir FQDN críticos para la empresa como *.microsoft.com, denegar dominios de uso compartido de archivos como *.torrent) y reglas de inteligencia sobre amenazas (bloquear direcciones IP malintencionadas conocidas de fuentes de amenazas de Microsoft Defender).
• Filtrado de direcciones URL y bloqueo basado en categorías: Se han implementado reglas de aplicación basadas en FQDN para un control de dominio preciso y filtrado basado en categorías para bloquear todas las categorías de sitios web (Hackeo, Redes sociales, Juegos de azar) al tiempo que se permiten categorías relacionadas con el trabajo (Business/Economy, Technology/Internet), aplicando directivas de uso aceptables en el perímetro de la red.
• Inspección de TLS para el tráfico HTTPS: Se ha habilitado la inspección tls con certificados almacenados en Azure Key Vault, lo que permite que el firewall descifre, inspeccione y vuelva a cifrar el tráfico HTTPS para un filtrado de direcciones URL más profundo y la detección de amenazas más allá de la inspección basada en SNI, a la vez que se excluyen los dominios bancarios confidenciales del descifrado por requisitos de cumplimiento.

Resultado: La organización estableció visibilidad centralizada y control sobre todo el tráfico dirigido a Internet y el tráfico entre radios, lo que elimina el desfase de directivas y los puntos ciegos de seguridad. La inspección de TLS habilitó la detección de amenazas ocultas en el tráfico HTTPS cifrado, mientras que el filtrado basado en categorías redujo considerablemente la exposición al contenido web de riesgo. La arquitectura de concentrador y periférico proporciona una postura de seguridad escalable y coherente en todas las cargas de trabajo con gestión unificada de políticas y protección completa contra amenazas.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

• NIST SP 800-53 Rev.5: SC-7, SC-7(5), AC-4, SI-4(4)
• PCI-DSS v4: 1.2.1, 1.3.1, 1.4.1, 1.4.2
• Cis Controls v8.1: 9.2, 9.3, 13.1
• NIST CSF v2.0: PR. AC-05, PR. PT-04, DE. CM-01
• ISO 27001:2022: A.8.20, A.8.22
• SOC 2: CC6.1, CC6.6, CC7.2

NS-4: Implementación de sistemas de prevención y detección de intrusiones (IDS/IPS)

Principio de seguridad

Use sistemas de detección de intrusiones de red y prevención de intrusiones (IDS/IPS) para inspeccionar el tráfico de red y carga hacia y desde la carga de trabajo o las redes virtuales. Asegúrese de que IDS/IPS esté siempre optimizado para proporcionar alertas de alta calidad a la solución SIEM.

Nota: Para una funcionalidad de detección y prevención más detallada del nivel de host, use IDS/IPS basado en host o una solución de detección y respuesta de punto final basada en host (EDR) en conjunto con el IDS/IPS de red.

Riesgo para mitigar

Los adversarios aprovechan vulnerabilidades en protocolos, aplicaciones y tráfico interno para ejecutar actividades malintencionadas.

• Vulnerabilidades de seguridad de protocolo: Las vulnerabilidades en protocolos como RDP (TCP 3389) o HTTP/HTTPS (TCP 80/443) permiten el acceso no autorizado o el riesgo del sistema a través de vulnerabilidades de seguridad como ataques dirigidos a CVE.
• Comunicaciones de comando y control (C2): Los servidores malintencionados establecen el control sobre los dispositivos en peligro a través de consultas DNS o devoluciones de llamada basadas en IP, lo que facilita la explotación persistente o la propagación de malware.
• Explotación de aplicaciones: Ataques como la inyección de código SQL, el cross-site scripting (XSS) o los desbordamientos de búfer aprovechan las vulnerabilidades de las aplicaciones para robar datos o ejecutar código arbitrario.
• Movimiento lateral: El tráfico interno anómalo, como la enumeración SMB (TCP 445) o el abuso de tickets de Kerberos (TCP 88), indica el movimiento del atacante dentro de la red.
• Filtración de datos: Las transferencias de datos no autorizadas se producen a través de canales cifrados (por ejemplo, POST HTTPS) o salida de gran volumen, mediante ofuscación para eludir la detección.

MITRE ATT&CK

• Acceso inicial (TA0001): intrusiones no autorizadas mediante exploits que apuntan a vulnerabilidades de red (por ejemplo, T1190 - Exploit de Aplicación Expuesta al Público).
• Ejecución (TA0002): ejecución de código malintencionado a partir de exploits de vulnerabilidad o payloads de C2 (por ejemplo, T1059 - intérprete de comandos y scripts).
• Comando y control (TA0011): comunicaciones de C2 de malware mediante consultas DNS o callbacks basados en IP (por ejemplo, T1071 - Protocolo de capa de aplicación).
• Movimiento lateral (TA0008): tráfico interno anómalo (por ejemplo, enumeración SMB) indicativo de pivotación (por ejemplo, T1021 - Servicios remotos).
• Filtración (TA0010): transferencias de datos no autorizadas a través de canales cifrados o ofuscados (por ejemplo, T1041 - Filtración a través del canal C2).

NS-4.1 Implementación de Azure Firewall Premium para IDPS

Los sistemas de detección y prevención de intrusiones proporcionan identificación de amenazas basada en firmas mediante la coincidencia de patrones de tráfico de red contra firmas de ataque conocidas, lo que permite el bloqueo en tiempo real de intentos de vulnerabilidades y comunicaciones malintencionadas. La funcionalidad IDPS de Azure Firewall Premium ofrece bibliotecas de firmas actualizadas continuamente que abarcan vulnerabilidades de seguridad, malware, comando y control, y categorías de suplantación de identidad (phishing) al tiempo que admiten modos de solo alerta y prevención. La selección y ajuste de firmas adecuadas garantizan la detección de alta fidelidad al tiempo que se minimizan los falsos positivos.

Implemente y configure IDPS mediante Azure Firewall Premium:

• Implementación de Azure Firewall Premium: Implemente Azure Firewall Premium con Premium Policy en la red virtual del centro para habilitar las funcionalidades de IDPS junto con otras características avanzadas, como la inspección de TLS y el filtrado de direcciones URL.

• Seleccione Reglas de firma de IDPS: Elija las reglas de firma de IDPS de la biblioteca de firmas en función de las prioridades de amenazas, empezando por firmas de alta gravedad en categorías críticas como "Malware", "Vulnerabilidades de seguridad" y "Phishing" que se alinean con el perfil de amenazas y la tolerancia a riesgos de su organización.

• Configurar el modo IDPS: Establezca el modo IDPS en Modo de alerta inicialmente para probar y ajustar para observar coincidencias de firma sin bloquear el tráfico y, a continuación, pasar al modo alerta y denegar para entornos de producción para evitar activamente amenazas detectadas al tiempo que mantiene alertas para la supervisión de seguridad.

• Ajustar las firmas: Ajuste las reglas de firma individuales en función de la experiencia operativa, deshabilite o reduzca la prioridad de las firmas que generan falsos positivos excesivos, a la vez que garantiza que las firmas de alta prioridad permanecen activas, optimizando la relación de señal a ruido para los equipos de operaciones de seguridad.

Ejemplo de implementación

Una organización necesitaba proteger la infraestructura crítica frente a vulnerabilidades de seguridad conocidas y ataques de día cero al tiempo que mantiene la visibilidad de la actividad de amenazas sin interrumpir las operaciones empresariales legítimas.

Desafiar: La organización operaba una aplicación web de varios niveles que procesaba transacciones financieras sin detección de amenazas basada en firmas más allá de las reglas básicas de firewall. Los equipos de seguridad no tenían visibilidad de los intentos de explotación que apuntan a los servidores de aplicaciones, no tenían capacidad para detectar comunicaciones de comando y control, y experimentaron alertas de falsos positivos de soluciones IDS genéricas que requieren un ajuste extenso.

Solution:

• Azure Firewall Premium con IDPS: Se implementó Azure Firewall Premium en la red virtual del centro de conectividad, lo que permite funcionalidades de IDPS junto con el filtrado de direcciones URL y inspección de TLS, lo que establece la detección centralizada de amenazas basada en firmas para todo el tráfico de red virtual radial.

• Selección de reglas de firma: Seleccione firmas IDPS de alta gravedad de categorías críticas, como Malware (Cobalt Strike, Metasploit, ransomware C2), Exploits (PaperCut CVE-2023-27350, Log4Shell, ProxyShell), phishing (recolección de credenciales) y patrones de comando y control.

• Modo de alerta y ajuste: IDPS configurado en modo de alerta para pruebas iniciales, observando coincidencias con firmas sin bloquear el tráfico, analizando alertas para identificar falsos positivos de las herramientas legítimas de DevOps y las llamadas de API de socios, y luego se crearon excepciones de firma para escenarios conocidos como buenos y mantener activas las firmas CVE de alta prioridad.

• Transición del modo de prevención: La IDPS ha pasado al modo de alerta y denegación para producción tras la validación, bloqueando activamente las amenazas detectadas, incluidos los intentos de explotación de PaperCut, los ataques de Log4Shell y las comunicaciones de C2.

• Integración de Sentinel: Ha configurado registros de diagnóstico en Log Analytics, ha creado reglas de análisis de Sentinel que correlacionan las detecciones de IDPS con eventos de autenticación y la creación automatizada de incidentes para alertas de alta gravedad.

Resultado: Los intentos de explotación se bloquearon correctamente para impedir la ejecución remota del código. Se eliminó la explotación de vulnerabilidad crítica antes de que se produjera un riesgo. Las tasas de falsos positivos disminuyeron considerablemente al tiempo que se mantiene una cobertura completa de CVE. Los equipos de seguridad lograron una rápida revisión de alertas y respuesta a incidentes, estableciendo visibilidad continua de amenazas con inteligencia accionable para la defensa proactiva.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

• NIST SP 800-53 Rev.5: SI-4, SI-4(4), SI-4(5), SC-7(5)
• PCI-DSS v4: 11.4.1, 11.4.2, 1.4.1
• Cis Controls v8.1: 13.2, 13.6, 13.7
• NIST CSF v2.0: DE. CM-01, DE. CM-04, DE. CM-07
• ISO 27001:2022: A.8.16, A.8.22, A.5.24
• SOC 2: CC6.1, CC7.2

NS-5: Desplegar protección contra DDOS

Azure Policy: Consulte Definiciones de directivas integradas de Azure: NS-5.

Principio de seguridad

Implemente la protección contra DDoS en varios niveles para mitigar eficazmente los ataques dirigidos a distintos servicios y protocolos en las capas de red y aplicación.

Riesgo para mitigar

Los actores de amenazas atacan redes, servidores o aplicaciones que usan un tráfico malintencionado abrumador para provocar interrupciones del servicio.

• Ataques volumétricos (inundación de red): Los atacantes inundan las interfaces de red con volúmenes de tráfico masivos (por ejemplo, millones de paquetes por segundo) para agotar el ancho de banda, la capacidad de procesamiento del enrutador o los recursos del equilibrador de carga, lo que provoca la falta de disponibilidad del servicio. Algunos ejemplos son los ataques UDP, los ataques ICMP o los ataques amplificados de reflexión DNS que utilizan protocolos como NTP o SSDP.
• Ataques de protocolo (agotamiento de estado): Los atacantes aprovechan las vulnerabilidades del protocolo de nivel 3/4 para agotar los recursos con estado, como tablas de conexión TCP o estados de sesión de firewall. Entre las técnicas comunes se incluyen las inundaciones de TCP SYN, que sobrecargan los servidores con conexiones semiabiertas, o las inundaciones de ACK destinadas a dispositivos con estado.
• Ataques de capa de recursos (sobrecarga de aplicación): Ataques de nivel 7 limitados, como inundaciones HTTP GET/POST, recursos de aplicación de destino (por ejemplo, CPU, memoria o conexiones de base de datos) para sobrecargar los servidores web o las API. Estos ataques tienen como objetivo agotar los recursos de proceso, lo que provoca picos de latencia o interrupciones.
• Ataques de amplificación: Los atacantes aprovechan servidores mal configurados (por ejemplo, servidores DNS, NTP o Plex Media en UDP 32414) para amplificar el tráfico, enviando consultas pequeñas que generan respuestas grandes dirigidas al destino, lo que sobrecarga la capacidad de red. Algunos ejemplos son los ataques de amplificación de DNS o de reflexión de SSDP.

MITRE ATT&CK

• Impacto (TA0040): interrumpe la disponibilidad del servicio a través de inundaciones volumétricas (por ejemplo, UDP/ICMP) o sobrecargas de recursos (por ejemplo, inundaciones HTTP) para denegar el acceso (por ejemplo, T1498- Denegación de servicio de red).
• Desarrollo de recursos (TA0042): aprovecha los sistemas comprometidos para ataques de amplificación (por ejemplo, reflexión DNS/NTP) para aumentar el impacto del ataque (por ejemplo, T1584 - Compromiso de infraestructura).

NS-5.1 Implementación de la protección contra DDOS en el nivel de red adecuado

Implemente la protección contra DDoS tanto en las capas de red como en las aplicaciones para defenderse contra ataques volumétricos y específicos de la aplicación. Azure proporciona varios niveles de protección: DDoS Network Protection para una cobertura completa de la red virtual con soporte de respuesta rápida, Protección IP de DDoS para la protección rentable de direcciones IP individuales y protección de capa de aplicación a través de WAF. Configure la supervisión y las alertas para validar la eficacia de la protección y garantizar la resistencia de las aplicaciones durante los ataques:

• Implementación de la protección contra DDoS de capa de red: Elija entre DDoS Network Protection para las implementaciones de cargas de trabajo que requieren una cobertura completa de red virtual y compatibilidad con la respuesta rápida para la investigación de ataques y el análisis posterior al ataque, o DDoS IP Protection para una protección rentable de un número limitado de direcciones IP sin compatibilidad con respuesta rápida.

• Implementación de la protección contra DDoS de capa de aplicación: Habilite la protección contra DDoS en Azure Web Application Firewall (WAF), Application Gateway o Azure Front Door para defenderse contra ataques de capa de aplicación (nivel 7).

• Configure la supervisión y las alertas: Configure alertas y supervise métricas y registros desde el servicio de protección contra DDoS y sus aplicaciones para garantizar la eficacia de la protección, la resistencia de las aplicaciones y el rendimiento deseado durante y después de los ataques.

Nota:

Incluso sin usar el servicio de protección contra DDoS anterior, Azure ofrece protección de la infraestructura DDoS, una protección de nivel de plataforma predeterminada en el nivel de infraestructura de red. Esta protección se proporciona de forma gratuita y no requiere ninguna configuración ni activación.

Ejemplo de implementación

Una organización de comercio electrónico necesitaba una protección completa contra DDoS para aplicaciones orientadas al cliente que experimentan intentos de ataque volumétricos y de capa de aplicación cada vez mayores durante las temporadas de compras máximas.

Desafiar: La organización operaba una plataforma global de comercio electrónico con aplicaciones web orientadas al público, API y infraestructura de entrega de contenido expuesta a Internet. Durante los eventos máximos, la plataforma experimentó varios ataques DDoS, incluidas las inundaciones UDP, las inundaciones TCP SYN que agotan las tablas de conexión del equilibrador de carga, las inundaciones HTTP dirigidas a las API de finalización de compra y los ataques de amplificación de DNS. Sin la protección DDoS dedicada, estos ataques provocaron interrupciones del servicio, lo que da lugar a pérdidas de ingresos y frustración de los clientes.

Solution:

• Protección de red DDoS: Se ha habilitado Azure DDoS Network Protection en redes virtuales de producción que hospedan aplicaciones orientadas al cliente, lo que proporciona una protección completa de nivel de red virtual con ajuste adaptable, detección automática de ataques en las capas 3 y 4 y mitigación en tiempo real.

• Protección de la capa de aplicación: Se implementó Azure Application Gateway con WAF para aplicaciones regionales y Azure Front Door con WAF para la entrega perimetral global, lo que permite la protección contra DDoS de nivel 7 con limitación de velocidad, detección de inundaciones HTTP y reglas de protección de bots.

• Configuración de la directiva de protección: Se ha creado un plan de protección contra DDoS que asocia todas las redes virtuales de producción, configura patrones de tráfico base para el aprendizaje de ajuste adaptativo, habilita la supervisión continua del tráfico y define directivas de protección que abarcan inundaciones de UDP, inundaciones de TCP SYN, inundaciones de ICMP y ataques de protocolo.

• Supervisión y alertas: Se configuraron los registros de diagnóstico de DDoS para enviar telemetría de ataques al área de trabajo de Log Analytics; se crearon alertas de Azure Monitor para desencadenar notificaciones inmediatas al detectar ataques; se estableció un libro de trabajo de Sentinel para correlacionar los ataques DDoS con las métricas de rendimiento de aplicaciones; y se configuró Application Insights para supervisar la salud de la aplicación durante la mitigación.

• Compromiso de Respuesta Rápida: Activada la Respuesta Rápida de DDoS, proporcionando acceso directo a los expertos en protección contra DDoS durante ataques activos para el análisis de ataques en tiempo real, el desarrollo de estrategias de mitigación personalizadas y el análisis forense post-ataque.

Resultado: Los ataques DDoS durante la temporada de compras punta se mitigaron correctamente con cero interrupciones del servicio. Las inundaciones volumétricas, las inundaciones SYN y las inundaciones HTTP se bloquearon automáticamente, manteniendo la disponibilidad de la plataforma. Respuesta rápida proporcionó un análisis experto para ataques sofisticados. Los períodos críticos de compras mantuvieron alta disponibilidad sin latencia en las transacciones de los clientes durante la mitigación.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

• NIST SP 800-53 Rev.5: SC-5, SC-5(1), SC-5(2), SI-4(4)
• PCI-DSS v4: 6.4.2, 11.4.7
• Cis Controls v8.1: 13.3
• NIST CSF v2.0: PR. PT-05, DE. CM-01
• ISO 27001:2022: A.8.13, A.8.24
• SOC 2: CC6.1, CC7.2

NS-6: Implementación de un firewall de aplicaciones web

Azure Policy: Consulte Definiciones de directivas integradas de Azure: NS-6.

Principio de seguridad

Implemente un firewall de aplicaciones web (WAF) y configure reglas para proteger las aplicaciones web y las API frente a ataques específicos de la aplicación inspeccionando, detectando y filtrando el tráfico HTTP/HTTPS malintencionado.

Riesgo para mitigar

Los atacantes aprovechan las vulnerabilidades de la aplicación web para obtener acceso no autorizado, ejecutar código malintencionado, robar credenciales o filtrar datos.

• Ataques por inyección de código (por ejemplo, inyección de código SQL, inyección de comandos): Los atacantes aprovechan las vulnerabilidades de validación de entrada para insertar código malintencionado en consultas o comandos de aplicaciones web, lo que permite el acceso no autorizado a la base de datos, la filtración de datos o el riesgo del sistema. La inyección SQL (SQLi) manipula las consultas del servidor (por ejemplo, anexando ' OR '1'='1' a un formulario de inicio de sesión), mientras que la inyección de comandos ejecuta comandos arbitrarios del sistema operativo (por ejemplo, ; rm -rf / mediante un campo de formulario).
• Infracciones del protocolo HTTP y solicitudes con formato incorrecto: Los atacantes envían solicitudes HTTP con formato incorrecto (por ejemplo, encabezados no válidos, cargas sobredimensionadas o métodos no estándar como TRACE) para aprovechar vulnerabilidades en servidores web o aplicaciones, lo que podría provocar bloqueos o acceso no autorizado. Estos ataques tienen como destino servidores mal configurados o marcos sin revisión.
• Ataques controlados por bots (por ejemplo, relleno de credenciales, extracción): los bots automatizados inician ataques de relleno de credenciales (por ejemplo, puntos de conexión de inicio de sesión por fuerza bruta con credenciales robadas) o extraen contenido confidencial (por ejemplo, datos de precios), sobrecargar servidores o poner en peligro las cuentas de usuario. Estos ataques aprovechan la autenticación débil o las API no protegidas.
• Vulnerabilidades de seguridad específicas de la aplicación (por ejemplo, inclusión remota de archivos, inclusión de archivos locales): Los atacantes aprovechan las vulnerabilidades para incluir archivos malintencionados (por ejemplo, incluir "http://evil.com/shell.php") o acceder a archivos de servidor local (por ejemplo, .). /.. /etc/passwd) a través de parámetros de dirección URL manipulados o entradas de formulario, lo que permite la ejecución de código o la exposición de datos.

MITRE ATT&CK

• Acceso inicial (TA0001): Aprovecha la inyección SQL, XSS o la inclusión remota de archivos para obtener acceso (por ejemplo, T1190 - Exploit de aplicaciones expuestas públicamente).
• Ejecución (TA0002): Ejecuta código malintencionado a través de la inserción de comandos, RFI o XSS (por ejemplo, T1059 - Intérprete de comandos y scripting).
• Acceso a credenciales (TA0006): Roba credenciales a través de XSS o relleno de credenciales (por ejemplo, T1539 - Robar cookie de sesión web, T1110 - Fuerza bruta).
• Colección (TA0009): Recopila datos a través de inyección o extracción de SQL (por ejemplo, T1213: datos de repositorios de información).

NS-6.1 Configuración de Azure WAF con reglas adecuadas

Habilite las funcionalidades del firewall de aplicaciones web (WAF) en Azure Application Gateway, Azure Front Door o Azure Content Delivery Network (CDN) para proteger las aplicaciones y las API frente a ataques basados en web. Seleccione el servicio adecuado en función de los requisitos de la aplicación, configure directivas waf con reglas integradas y personalizadas, establezca el modo de directiva en función de la posición de seguridad y asocie la directiva al punto de conexión de servicio:

• Seleccione el servicio WAF adecuado: Elija Azure Application Gateway para aplicaciones hospedadas en red virtual, Azure Front Door para la entrega perimetral global o Azure CDN para cargas de trabajo con mucho contenido en función de los requisitos y la arquitectura de la aplicación.

• Configuración de directivas waf con reglas integradas y personalizadas: Comience con conjuntos de reglas integrados comunes, como OWASP Core Rule Set (CRS 3.2) y reglas de protección de bots (Microsoft Bot Manager). Agregue reglas personalizadas (por ejemplo, limitación de velocidad para >100 solicitudes/min) y exclusiones para reducir los falsos positivos en función del panorama de amenazas y el perfil de seguridad de aplicaciones.

• Establecer el modo de directiva WAF: Use inicialmente el modo de detección o para aplicaciones no críticas para evitar interrumpir el tráfico legítimo durante la configuración y la optimización de reglas. Cambie al modo de prevención para las aplicaciones críticas una vez validadas las reglas para bloquear solicitudes malintencionadas.

• Asociación de la directiva WAF con el punto de conexión de servicio: Asocie la directiva WAF al punto de conexión de la pasarela de aplicaciones, Front Door o el CDN para asegurarse de que todo el tráfico HTTP/HTTPS se enruta a través de WAF para su inspección.

Ejemplo de implementación

Una organización necesitaba proteger las aplicaciones web orientadas al cliente y las API frente a la inyección de código SQL, los ataques XSS y las credenciales controladas por bots, a la vez que se mantiene el rendimiento de los usuarios legítimos.

Desafiar: La organización tenía aplicaciones web implementadas globalmente sin protección contra las 10 vulnerabilidades principales de OWASP, lo que da lugar a varios intentos de inyección de código SQL, ataques controlados por bots que sobrecargan los puntos de conexión de inicio de sesión y no hay visibilidad de los patrones de tráfico malintencionados. Las aplicaciones no tenían controles de limitación de velocidad, lo que permitía ataques de uso indebido de API y de relleno de credenciales, y no había ningún mecanismo para distinguir a los usuarios legítimos de los bots malintencionados.

Enfoque de solución:

• Selección del servicio WAF: Azure Application Gateway implementado con WAF para aplicaciones hospedadas en red virtual y Azure Front Door con WAF para aplicaciones distribuidas globalmente que requieren protección perimetral y acceso de baja latencia.
• Conjuntos de reglas de protección integrados: Se ha habilitado OWASP Core Rule Set (CRS) 3.2 para protegerse contra la inyección de código SQL, el scripting entre sitios (XSS), la inclusión remota de archivos y otras vulnerabilidades web comunes, y ha activado las reglas de Microsoft Bot Manager para identificar y bloquear bots malintencionados, al tiempo que permite rastreos legítimos del motor de búsqueda y servicios de supervisión.
• Reglas personalizadas para amenazas específicas: Se han implementado reglas de limitación de velocidad que bloquean a los clientes que superan las 100 solicitudes por minuto para evitar el abuso de API y el relleno de credenciales, las reglas de filtrado geográfico bloquean el tráfico de regiones de alto riesgo donde los servicios no están disponibles y las reglas basadas en la reputación de IP que bloquean las solicitudes de intervalos IP malintencionados conocidos identificados a través de fuentes de inteligencia sobre amenazas.
• Administración de exclusión: Se crearon exclusiones dirigidas para escenarios empresariales legítimos, como puntos de conexión /checkout con entradas de formulario complejas que desencadenaron falsos positivos en reglas de OWASP, /upload endpoints que controlan envíos de archivos grandes y puntos de conexión /api con patrones de encabezado inusuales pero válidos de aplicaciones móviles.
• Transición de detección a prevención: Iniciamos el WAF en modo de detección durante dos semanas para identificar falsos positivos, refinar las reglas y las exclusiones basadas en patrones de tráfico legítimos, y luego pasamos al modo de prevención para que las aplicaciones de producción bloqueen activamente las amenazas mientras mantienen la continuidad empresarial.

Resultado: La organización eliminó los intentos de inyección de CÓDIGO SQL y de explotación XSS, redujo considerablemente los ataques controlados por bots a través de reglas del administrador de bots y estableció una visibilidad completa de las amenazas de la aplicación web. Los controles de limitación de velocidad evitaron el abuso de API y el relleno de credenciales, mientras que la transición por fases de la detección al modo de prevención garantizaba que los usuarios legítimos no experimentaran ninguna interrupción del servicio.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

• NIST SP 800-53 Rev.5: SC-7, SC-7(5), SI-10, SI-10(1), SI-11
• PCI-DSS v4: 6.4.1, 6.4.2, 11.4.7
• Cis Controls v8.1: 13.2, 13.9
• NIST CSF v2.0: PR. AC-05, PR. PT-05, DE. CM-04
• ISO 27001:2022: A.8.20, A.8.22, A.8.25
• SOC 2: CC6.1, CC6.6, CC7.2

NS-7: Administrar la seguridad de red de forma centralizada y eficaz

Principio de seguridad

Para reducir el riesgo operativo y la configuración incorrecta en entornos de red complejos y fragmentados, use características de administración de red nativas en la nube para centralizar, simplificar y aplicar configuraciones de seguridad de red coherentes.

Riesgo para mitigar

La falta de control centralizado da lugar a configuraciones de seguridad pasadas por alto o desactualizadas, lo que aumenta el riesgo de explotación.

• Cumplimiento de directivas incoherente y configuraciones incorrectas: La administración descentralizada a menudo conduce a conjuntos de reglas fragmentados y brechas de directivas, lo que facilita a los atacantes detectar y aprovechar puntos débiles. Las configuraciones incorrectas son más probables, lo que aumenta las posibilidades de exposición accidental o acceso no deseado.
• Visibilidad reducida y respuesta retrasada: Sin un enfoque de administración unificado, la supervisión y la respuesta a incidentes se vuelven más lentas y menos eficaces. Esto puede retrasar la detección de actividades malintencionadas, lo que permite a los atacantes más tiempo escalar ataques o filtrar datos.
• Dificultad para mantener el cumplimiento: La administración central inadecuada complica los esfuerzos para cumplir de forma coherente los estándares normativos y del sector, arriesgando el incumplimiento y las posibles sanciones.

MITRE ATT&CK

• Acceso inicial (TA0001): Explotación de vulnerabilidades debido a configuraciones incorrectas o configuraciones de seguridad obsoletas para obtener acceso no autorizado (por ejemplo, T1190 - Explotación de aplicación de cara al público, T1133 - Servicios remotos externos).
• Evasión de defensa (TA0005): Aprovechar los conjuntos de reglas fragmentados y la falta de supervisión centralizada para evitar la detección (por ejemplo, T1562 - Debilitar defensas).
• Movimiento lateral (TA0008): Mover lateralmente a través de la red aprovechando brechas de directiva o segmentación obsoleta (por ejemplo, T1021 - Servicios remotos).
• Comando y control (TA0011): Usar rutas de red no supervisadas o mal configuradas para establecer y mantener canales C2 (por ejemplo, T1071 - Protocolo de capa de aplicación).

NS-7.1 Administrar la seguridad de red de forma centralizada y eficaz

Utiliza las herramientas centralizadas de Azure y las prácticas estandarizadas para simplificar y ampliar la gestión de la seguridad de redes, lo que garantiza una aplicación coherente, la reducción de configuraciones incorrectas, y una mejora en la supervisión. Implemente la aplicación centralizada de directivas, normalice el firewall y la administración de enrutamiento, habilite la supervisión y el análisis completos y mantenga la coherencia de los recursos a través de las prácticas de gobernanza:

• Implementar la aplicación centralizada de directivas: Use Azure Virtual Network Manager (AVNM) para definir reglas de administración de seguridad que se aplican de forma coherente entre suscripciones y regiones. Conservar los grupos de seguridad de red para la microsegmentación a nivel de cargas de trabajo. Aplicar políticas a través de grupos de red (por ejemplo, por entorno: producción, no producción).

• Estandarizar el firewall y la administración de enrutamiento: Administre las reglas de Azure Firewall a través de Firewall Manager con objetos de directiva de firewall. Estandarice en grupos de IP y etiquetas de servicio en lugar de IPs crudas. Use Azure Firewall Premium donde se requieren la inspección de TLS, IDPS y el filtrado de direcciones URL. Prefiere hubs seguros de Virtual WAN o una topología compartida de hub-and-spoke para aplicar la intención de enrutamiento de forma coherente.

• Habilite la supervisión y el análisis completos: Use los registros de flujo de red virtual v2 (para reemplazar los registros de flujo de NSG). Habilite los registros de diagnóstico de Azure Firewall e integre con Traffic Analytics, Log Analytics y Microsoft Sentinel. Para eliminar las reglas no utilizadas o duplicadas, utilice los Analytics de políticas de firewall y los conteos de impacto de reglas.

• Mantener la coherencia y la gobernanza de los recursos: Aplique convenciones de nomenclatura de CAF y etiquetas de recursos obligatorias a todas las redes virtuales, grupos de seguridad de red, reglas de firewall y grupos. Use la protección de red adaptable de Defender for Cloud para refinar las reglas excesivamente permisivas.

Ejemplo de implementación

Caso de uso: La plataforma de pago en varias regiones consolida la seguridad de red a escala

Contexto: Un procesador de pagos de tamaño medio que opera en el Este de EE. UU. y el Oeste de Europa con 4 suscripciones (Prod, Non-Prod, Shared Services, SecOps) bajo un solo arrendatario necesita segmentación PCI-DSS, menos incidentes por deriva de reglas y supervisión centralizada.

Aplicación centralizada de directivas con Azure Virtual Network Manager:

• Diseño: Cree AVNM en el nivel de grupo de administración. Defina dos grupos de red: ng-prod y ng-nonprod con pertenencia dinámica por etiqueta subscriptionId. Cree reglas de administración de seguridad (SAR) para aplicar barreras de seguridad de la organización que se evalúen antes que los grupos de seguridad de red: Deny-Inbound-Internet-to-Spokes (bloquea la entrada no solicitada de Internet a todas las subredes de satélite), Allow-Hub-Infra (permite servicios del concentrador - Firewall/Bastion - en satélites), Allow-Platform-DNS (permite DNS de resolutores del concentrador a los satélites).
• Límites del equipo de aplicaciones: Las cargas de trabajo mantienen los NSGs para la microsegmentación (por ejemplo, web a API :443, API a db :1433) dentro de cada segmento. Los cambios de NSG están a cargo de los equipos de aplicaciones; las SAR están a cargo del equipo de seguridad de la plataforma.
• Resultado: Los límites de protección son coherentes en ambas regiones; Los equipos de aplicaciones no pueden crear accidentalmente acceso directo a Internet incluso si un NSG está mal configurado.

Administración de firewalls y enrutamiento con Firewall Manager y Virtual WAN:

• Diseño: Implemente centros seguros de Virtual WAN en cada región (Este de EE. UU., Oeste de Europa). Conecte los ramales al concentrador más cercano y active la intención de enrutamiento para que se inspeccione toda la salida de tráfico a Internet. Utilice Firewall Manager con una política global de Firewall (nivel: Premium) y dos políticas secundarias (Prod/Non-Prod) para ajustes de entorno.
• Estructura de directivas: La directiva base (global) incluye inteligencia sobre amenazas configurada para Alertar y Denegar, inspección de TLS habilitada para HTTPS saliente, IDPS en modo balanceado y reglas de permiso de salida mediante Service Tags (Storage, KeyVault, AzureMonitor) y grupos de IP para puntos de conexión de partners. La política secundaria de Prod tiene un filtrado de URLs más estricto (bloquear las no categorizadas) y una lista de permitidos para las pasarelas de pago a través de Grupos IP. La política secundaria de Non-Prod tiene acceso más amplio a herramientas de desarrollo a través de Etiquetas de Servicio (AzureDevOps, AzureContainerRegistry).
• Resultado: Panel único para administrar reglas con cambios que se propagan a ambos nodos. El enrutamiento es coherente y todas las salidas se inspeccionan con el descifrado TLS cuando se permite.

Supervisión y análisis con los registros de flujo v2 y Sentinel:

• Configuración de telemetría: Habilite los registros de flujo de red virtual v2 en todas las redes virtuales y envíe a un área de trabajo central de Log Analytics en la suscripción de SecOps. Configure los registros de diagnóstico de Azure Firewall (Aplicación, Red, DNS, ThreatIntel, IDPS) en la misma área de trabajo. Habilitar Análisis de tráfico contra el espacio de trabajo.
• Bucle de optimización: Habilite el Análisis de Directivas de Firewall y revise los recuentos de aciertos de las reglas mensualmente. Cree un libro de Sentinel que ponga en correlación los registros de flujo (norte-sur y este-oeste), permitir o denegar aciertos del firewall y las firmas IDPS desencadenadas. Automatice una solicitud de cambio si una regla tiene 0 coincidencias durante 45 días (candidato a eliminación) o si una subred de producción coincide con una regla de denegación (posible error de enrutamiento).
• Resultado: Después de dos ciclos de revisión, se quitan 18% de reglas de firewall y 22 reglas de NSG obsoletas, lo que reduce la latencia de evaluación de reglas y el riesgo de cambio.

Coherencia y gobernanza de recursos con CAF y Defender for Cloud:

• Normas: Aplique la nomenclatura de CAF (por ejemplo, vnet-prd-eus-01, nsg-prd-eus-web-01, azfw-policy-global-01) y etiquetas obligatorias: env, owner, dataClass, costCenter.
• Aplicación: Use iniciativas de Azure Policy para requerir NSG en cada subred, requerir la configuración de diagnóstico en redes virtuales y firewall en el área de trabajo central de LA y denegar la creación sin etiquetas obligatorias. Habilitar Defender for Cloud: endurecimiento adaptativo de la red en todos los ramales, con elementos de acción semanales revisados en SecOps CAB.
• Resultado: El desfase de plataforma se muestra rápidamente; las reglas demasiado permisivas se ajustan mediante las recomendaciones basadas en datos de Defender.

Criterios de aceptación y secuencia de lanzamiento:

• Implante concentradores seguros de vWAN, conecte ramas, habilite la intención de enrutamiento (solo ramas piloto). Criterios de aceptación: salida piloto de radios a través del firewall; no se puede acceder directamente a direcciones IP públicas.
• Implemente SARs de AVNM en ng-nonprod, verifique que no haya interrupciones y, a continuación, en ng-prod. Criterios de aceptación: los sondeos sintéticos confirman que los servicios centrales (DNS/Bastion) siguen conectándose a los radios; el acceso entrante a Internet sigue siendo denegado.
• Habilite los registros de flujo vNet v2 y todos los diagnósticos del firewall; integrar el libro de trabajo de Sentinel. Criterios de aceptación: los paneles muestran flujos, denegaciones, incidencias de IDPS por región.
• Aplicar iniciativas de políticas de seguridad; remediar elementos no conformes; habilitar el endurecimiento adaptativo. Criterios de aceptación: el cumplimiento alcanza los 95%, trabajo pendiente de NSG o elementos de ajuste de firewall creados.
• Primera revisión de Análisis de políticas; quite las reglas sin usar a través de la ventana de cambio. Criterios de aceptación: el número de reglas se redujo en 15% con un impacto cero en el cliente.

Ejemplos de manual de operaciones:

• Reglas de Administración de Seguridad de Azure Virtual Network Manager: Denegar la Entrada de Internet a los Brazos (prioridad 100), Permitir la Infraestructura del Concentrador a los Brazos (prioridad 200: src 10.0.0.0/16 intervalos de Concentradores)
• Estructura de directivas de firewall: azfw-policy-global-01 (Premium) con colecciones de reglas Allow-Azure-Platform-ST (Etiquetas de Servicio) y Allow-Partners-IPs (Grupos de IP: ipg-payment-gws), además de políticas secundarias azfw-policy-prd-01 y azfw-policy-npd-01
• Diagnósticos: Destino: law-secops-01, Categories: AZFWApplicationRule, AZFWNetworkRule, AZFWIDPS, AZFWThreatIntel, AZFWDnsProxy, FlowLogV2

Nivel de importancia crítica

Imprescindible.

Asignación de controles

• NIST SP 800-53 Rev.5: CM-2, CM-3, CM-6, CA-7, SI-4
• PCI-DSS v4: 1.4.5, 11.5.1, 12.4.1
• Cis Controls v8.1: 4.1, 4.2, 12.4, 13.6
• NIST CSF v2.0: PR.IP-01, DE.CM-01, DE.CM-07
• ISO 27001:2022: A.8.9, A.8.32, A.5.37
• SOC 2: CC6.6, CC7.2, CC8.1

NS-8: Detección y deshabilitación de protocolos y servicios no seguros

Azure Policy: Consulte Definiciones de directivas integradas de Azure: NS-8.

Principio de seguridad

Descubra y deshabilite los servicios y protocolos no seguros en el sistema operativo, la aplicación o el nivel de paquete de software. Implementar controles de compensación si no es posible deshabilitar los servicios y protocolos no seguros.

Riesgo para mitigar

Los actores de amenazas aprovechan los servicios y protocolos no seguros y vulnerables para poner en peligro los sistemas y los datos.

• Vulnerabilidad criptográfica: SSL/TLSv1 y cifrados débiles (por ejemplo, RC4, DES) son vulnerables a ataques MITM (por ejemplo, POODLE, BEAST), lo que permite a los adversarios descifrar datos confidenciales como tokens de sesión a través de oráculos de relleno o ataques de texto cifrado elegido.
• Acceso no autorizado a través de vulnerabilidades de seguridad de protocolo: Las vulnerabilidades SSHv1 y SMBv1 (por ejemplo, CVE-2001-1473, CVE-2017-0144/EternalBlue) permiten la ejecución remota del código o el acceso no autenticado, lo que permite los puntos de conexión iniciales.
• Robo de credenciales: LM/NTLMv1 y wDigest almacenan hashes débiles o credenciales en texto no cifrado, vulnerables a pase de hash o extracción de memoria (por ejemplo, Mimikatz extrayendo datos de LSASS).
• Movimiento lateral: Las sesiones y vulnerabilidades de seguridad sin cifrar de SMBv1 (por ejemplo, EternalBlue) permiten la propagación de malware o la retransmisión de credenciales entre redes.

MITRE ATT&CK

• Acceso inicial (TA0001): La explotación de protocolos inseguros, como SSL/TLSv1 o SSHv1, que son vulnerables a ataques de degradación de protocolo o exploits conocidos, para bloquear entradas no autorizadas (por ejemplo, T1190 - Explotación de aplicaciones con acceso público).
• Acceso a credenciales (TA0006): Robo de credenciales mediante la explotación de LM/NTLMv1 y wDigest, que almacenan credenciales en formatos reversibles o hashes débiles, lo que dificulta la técnica de pass-the-hash o la extracción de memoria (por ejemplo, T1003 - Volcado de credenciales del sistema operativo).
• Movimiento lateral (TA0008): Impide que el atacante dinamiza SMBv1 que sea vulnerable a vulnerabilidades de seguridad como EternalBlue, evitando la propagación entre redes (por ejemplo, T1021 - Servicios remotos).

NS-8.1 Detectar y deshabilitar protocolos y servicios no seguros

Use el libro de protocolo inseguro integrado de Microsoft Sentinel para detectar y mitigar los servicios y protocolos no seguros en todo el entorno de Azure. Este libro identifica el uso de protocolos y servicios que no cumplen los estándares de seguridad adecuados, como SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, cifrados débiles en Kerberos y enlaces LDAP sin firmar. Después de la identificación, deshabilite estos protocolos y servicios no seguros. Cuando la deshabilitación no es factible, implemente controles de compensación para reducir la superficie expuesta a ataques.

Detectar protocolos no seguros: Use el libro de protocolos no seguros de Microsoft Sentinel para identificar el uso de cifrados SSL/TLSv1, SSHv1, SMBv1, LM/NTLMv1, wDigest, cifrados Kerberos débiles y enlaces LDAP sin firmar en todo el entorno.

Deshabilite los servicios y protocolos no seguros: Deshabilite los servicios y protocolos no seguros identificados que no cumplan los estándares de seguridad adecuados para eliminar las vulnerabilidades.

Implementar controles de compensación: Si no es posible deshabilitar los servicios o protocolos no seguros debido a requisitos empresariales o restricciones técnicas, use controles de compensación, como bloquear el acceso a los recursos a través de grupos de seguridad de red, Azure Firewall o Azure Web Application Firewall para reducir la superficie expuesta a ataques.

Ejemplo de implementación

Una organización sanitaria necesitaba eliminar protocolos inseguros en su entorno de Azure para cumplir con los requisitos de HIPAA y reducir la superficie de ataque para la información de salud protegida.

Desafiar: La organización ha operado una infraestructura híbrida con aplicaciones heredadas que requieren conectividad a recursos hospedados en Azure. La evaluación de seguridad reveló un uso generalizado de protocolos inseguros, como SSL/TLSv1.0 en servidores web que atienden portales de pacientes, SMBv1 habilitado en servidores de archivos para software de imágenes médicas heredadas, autenticación LM/NTLMv1 en controladores de dominio y servidores de aplicaciones, autenticación wDigest almacenando credenciales en formato reversible, enlaces LDAP sin firmar en controladores de Active Directory y cifrado Kerberos débil en cuentas de servicio. La organización no tenía visibilidad sobre el uso del protocolo y se enfrentaba a posibles infracciones de cumplimiento de HIPAA.

Solution:

• Implementación del libro de protocolo no seguro de Sentinel: Implementó Microsoft Sentinel e instaló El libro de protocolo no seguro desde el centro de contenido, orígenes de datos conectados, incluidos los registros de eventos de seguridad de Windows, los registros de Azure Monitor, los registros de Active Directory y los registros de flujo de red, estableciendo una línea de base completa del uso de protocolos no seguros en todo el entorno híbrido.

• Detección de protocolos: Se usa el libro de protocolo no seguro para identificar el uso de SSL/TLSv1.0 en servidores web, el tráfico SMBv1 de estaciones de trabajo de imágenes médicas heredadas, patrones de autenticación LM/NTLMv1, wDigest habilitado en servidores Windows, enlaces LDAP sin firmar de aplicaciones heredadas y cifrado RC4 Kerberos débil en cuentas de servicio.

• Deshabilitación sistemática del protocolo: Se ha creado un plan de corrección por fases validado a través del consejo de asesoramiento de cambios, se deshabilitó TLSv1.0/1.1 en servidores web después de confirmar que los usuarios del portal de pacientes operaban navegadores modernos compatibles con TLS 1.2+, se deshabilitó SMBv1 después de coordinar con las actualizaciones de software del proveedor de imágenes médicas, se realizó la transición de la autenticación NTLMv1 a NTLMv2 en los controladores de dominio, se deshabilitó wDigest a través de la Directiva de Grupo, se aplicó la firma LDAP en los controladores de dominio y se actualizó el cifrado Kerberos de la cuenta de servicio a AES256.

• Controles de compensación para excepciones: Se han implementado controles de compensación basados en red para sistemas que requieren compatibilidad temporal con protocolos inseguros, incluida la VLAN aislada para estaciones de trabajo de imágenes médicas heredadas que requieren SMBv1, reglas de NSG que restringen el tráfico SMBv1 exclusivamente a la VLAN aislada, Azure Firewall denegando la salida SMBv1 desde subredes de producción, servidor de salto dedicado para aplicaciones de RR. HH. heredadas y supervisión mejorada a través de Defender for Endpoint que señala el uso del protocolo fuera de las subredes de excepción aprobadas.

• Supervisión continua: Se estableció la higiene continua del protocolo a través de las reglas de análisis de Microsoft Sentinel que desencadenan alertas para nuevas conexiones de protocolo no seguras fuera de las excepciones aprobadas, la denegación de la implementación de Azure Policy sin el requisito mínimo de TLS 1.2 y las revisiones semanales del libro del protocolo no seguro revisan el progreso de la corrección.

Resultado: Las conexiones TLS débiles se eliminaron de los portales de pacientes. SMBv1 se deshabilitó después de las actualizaciones de imágenes médicas, eliminando la vulnerabilidad de EternalBlue y logrando el cumplimiento de HIPAA. NTLMv1 ha pasado a NTLMv2, lo que impide ataques pass-the-hash. wDigest deshabilitó el robo de credenciales mitigado. La firma LDAP bloqueó las consultas que no estaban firmadas. Kerberos se actualizó a AES256, lo que reduce el riesgo de Kerberoasting. Los controles de compensación contenían sistemas heredados con movimiento lateral cero. Cumplimiento completo de HIPAA logrado.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

• NIST SP 800-53 Rev.5: SC-8, SC-8(1), SC-13, IA-5(1)
• PCI-DSS v4: 2.2.4, 4.2.1, 6.2.4
• Cis Controls v8.1: 4.8, 9.3, 13.4
• NIST CSF v2.0: PR. DS-02, PR. IP-01, DE. CM-04
• ISO 27001:2022: A.8.24, A.8.26, A.5.14
• SOC 2: CC6.1, CC6.7, CC7.1

NS-9: Conexión privada a una red local o en la nube

Principio de seguridad

Use conexiones privadas para una comunicación segura entre diferentes redes, como centros de datos del proveedor de servicios en la nube y la infraestructura local en un entorno de coubicación.

Riesgo para mitigar

Cuando los datos viajan a través de redes públicas, es vulnerable a la interceptación, el acceso no autorizado y la manipulación.

• Interceptación de datos: Cuando los datos viajan a través de redes públicas como Internet, pasa a través de varios enrutadores, conmutadores y proveedores de servicios, cualquiera de los cuales podría estar en peligro o supervisado por actores malintencionados. Los atacantes pueden implementar herramientas de detección de paquetes (por ejemplo, Wireshark) para capturar paquetes de datos. Si los datos están sin cifrar o no están cifrados de forma débil, se puede exponer información confidencial, como credenciales de inicio de sesión, detalles financieros o datos empresariales propietarios.
• Ataques man-in-the-middle (MitM): En un ataque MitM, un atacante intercepta secretamente y potencialmente modifica la comunicación entre dos partes que creen que se comunican directamente entre sí. Esto supone una amenaza grave para las operaciones confidenciales, como transacciones financieras o procesos de autenticación.
• Acceso no autorizado: Las redes públicas o inadecuadamente protegidas aumentan la probabilidad de que los usuarios no autorizados obtengan acceso o manipulan los sistemas o recursos privados. Los atacantes pueden aprovechar las debilidades de red para llegar a la infraestructura interna que debe permanecer inaccesible desde el exterior.

MITRE ATT&CK

• Acceso inicial (TA0001): Explotación de protocolos no cifrados o débilmente cifrados (p.ej., HTTP o versiones obsoletas de TLS) vulnerables a la interceptación de paquetes o ataques de Hombre en el Medio (MitM), lo que permite la entrada no autorizada en sistemas (p.ej., T1190 - Explotar aplicación de cara al público).
• Acceso a credenciales (TA0006): Robo de credenciales a través del tráfico de red interceptado, aprovechar protocolos de texto no cifrado (por ejemplo, Telnet o FTP) o cifrado débil susceptible a descifrado, lo que facilita el acceso no autorizado (por ejemplo, T1040 - Detección de red).
• Movimiento lateral (TA0008): Propagación dentro de redes aprovechando servicios mal configurados o expuestos (por ejemplo, RDP o SMB no revisados), lo que permite a los atacantes dinamizar mediante credenciales o vulnerabilidades robadas (por ejemplo, T1021 - Servicios remotos).

NS-9.1 Uso de la red privada virtual (VPN) de Azure para una conectividad ligera de sitio a sitio o de punto a sitio

Use la red privada virtual (VPN) de Azure para crear conexiones seguras y cifradas entre sitios locales o dispositivos de usuario final y redes virtuales de Azure para escenarios de conectividad ligeros. Vpn de Azure proporciona una solución rentable para la conectividad de sitio a sitio (conexión de redes completas) o conectividad de punto a sitio (conexión de dispositivos individuales) sin necesidad de una infraestructura dedicada:

• Implementación de VPN de sitio a sitio: Use VPN de sitio a sitio para conectar de forma segura la red local a la red virtual de Azure, lo que permite una comunicación sin problemas entre los recursos locales y las cargas de trabajo de Azure.

• Implementación de VPN de punto a sitio: Use vpn de punto a sitio para permitir que los dispositivos individuales de usuario final (portátiles, estaciones de trabajo) se conecten de forma segura a la red virtual de Azure desde ubicaciones remotas.

NS-9.2 Uso de Azure ExpressRoute (o Virtual WAN) para conexiones de alto rendimiento de nivel empresarial

Use Azure ExpressRoute o Azure Virtual WAN para establecer conexiones privadas, de alto rendimiento y de baja latencia entre los centros de datos de Azure y la infraestructura local en entornos de coubicación. Estas soluciones de nivel empresarial omiten la red pública de Internet, lo que proporciona ancho de banda dedicado, rendimiento predecible y seguridad mejorada para cargas de trabajo críticas que requieren conectividad coherente:

• Implemente ExpressRoute para la conectividad privada dedicada: Use Azure ExpressRoute para crear una conexión privada entre la infraestructura local y los centros de datos de Azure a través de un proveedor de conectividad, lo que garantiza un ancho de banda dedicado y una latencia predecible para cargas de trabajo empresariales.

• Implementación de Virtual WAN para la conectividad global: Use Azure Virtual WAN para crear una red global que conecte varios sitios, ramas y regiones de Azure a través de una arquitectura unificada de concentrador y radio con funcionalidades de seguridad y enrutamiento integradas.

NS-9.3 Uso de emparejamiento de VNets o subredes para unir redes virtuales

Use el emparejamiento de red virtual o el emparejamiento de subredes para establecer la conectividad privada entre redes virtuales de Azure sin enrutar el tráfico a través de la red pública de Internet. El tráfico de red entre redes virtuales emparejadas permanece en la red troncal de Azure, lo que proporciona conexiones de baja latencia y ancho de banda alto sin sobrecarga de cifrado. Elija emparejamiento de subred cuando la conectividad completa de red virtual no sea necesaria, lo que limita la exposición a solo subredes específicas:

• Implementación del emparejamiento de redes virtuales: Use el emparejamiento de redes virtuales para conectar redes virtuales de Azure completas, lo que permite que los recursos de diferentes redes virtuales se comuniquen de forma privada como si estuvieran en la misma red.

Ejemplo de implementación

Una organización multinacional de servicios financieros necesitaba conectividad segura y de alto rendimiento entre centros de datos locales, sucursales y recursos en la nube de Azure, al tiempo que eliminaba la exposición pública a Internet para transacciones financieras confidenciales.

Desafiar: La organización operaba varios centros de datos locales con sucursales globalmente, lo que requiere conectividad con aplicaciones hospedadas en Azure que procesan transacciones financieras y datos de clientes. La arquitectura inicial usó VPN de sitio a sitio a través de Internet, experimentando una latencia impredecible, limitaciones de ancho de banda durante las horas punta del comercio, preocupaciones de seguridad sobre los datos financieros que atraviesan la red pública de Internet a pesar del cifrado y los requisitos de cumplimiento que exigen conectividad privada para PCI-DSS y RGPD. Los empleados remotos que se conectan a través de vpn de punto a sitio experimentaron problemas de autenticación y rendimiento incoherentes. Las aplicaciones de diferentes regiones de Azure requerían una comunicación entre regiones de baja latencia sin enrutamiento a través de centros locales.

Solution:

• ExpressRoute para la conectividad del centro de datos principal: Se implementaron circuitos de Azure ExpressRoute en los centros de datos principales a través de instalaciones de colocalización con proveedores de conectividad de ExpressRoute, estableciendo la conectividad privada de Capa 3 a la red troncal de Azure con baja latencia constante, configurando ExpressRoute con emparejamiento de Microsoft para servicios PaaS de Azure y emparejamiento privado para recursos hospedados en red virtual, se implementó enrutamiento BGP con configuración activa-activa para alta disponibilidad y conmutación automática por error.

• VPN de sitio a sitio para la conectividad de sucursal: VPN de sitio a sitio implementada para sucursales que carecen de acceso a instalaciones de ubicación conjunta, creando un VPN Gateway en la nube virtual del centro de conectividad con configuración activa-activa para alta disponibilidad. Túneles IPsec/IKE configurados con criptografía sólida que cumple con los estándares de seguridad del sector financiero. Implementado enrutamiento BGP para la selección dinámica de rutas, permitiendo a las sucursales conectarse al centro regional más cercano. Túneles redundantes establecidos para garantizar la conectividad durante las ventanas de mantenimiento.

• VPN de punto a sitio para empleados remotos: Configurada la VPN de punto a sitio con autenticación de Azure Active Directory para empleados remotos que requieren acceso seguro a aplicaciones hospedadas en Azure, se habilitó la autenticación basada en certificados como respaldo para escenarios sin acceso a Internet a Azure AD, se asignaron direcciones IP de cliente desde un grupo dedicado, enrutadas a recursos de la red virtual de Azure mediante rutas definidas por el usuario, se implementó el protocolo OpenVPN para clientes macOS/Linux y IKEv2/SSTP para clientes Windows, proporcionando una amplia compatibilidad con dispositivos. Se configuró la tunelización dividida, permitiendo el acceso directo a Internet para el tráfico no corporativo, mientras se enruta el tráfico hacia Azure a través del túnel VPN y optimiza el ancho de banda.

• Virtual WAN para la conectividad de malla global: Implementación de Azure Virtual WAN con hubs seguros en varias regiones que proporcionan una arquitectura de tránsito global, con circuitos ExpressRoute conectados a hubs de Virtual WAN que permiten la conectividad completa de cualquier-a-cualquier entre los centros de datos y las regiones de Azure sin necesidad de enrutamiento a través de hubs locales, conexiones VPN integradas de sitio a sitio desde sucursales al hub de Virtual WAN más cercano con una optimización automática del enrutamiento, Azure Firewall habilitado en cada hub de Virtual WAN proporcionando una inspección de seguridad centralizada para tráfico entre sucursales, centros de datos y redes virtuales de Azure, y directivas de enrutamiento configuradas que implementan el enrutamiento de tránsito global, permitiendo a las sucursales comunicarse con centros de datos locales a través de la red troncal de Azure.

• Emparejamiento de red virtual para la conectividad entre regiones de Azure: Implementación del emparejamiento de red virtual que conecta VNets de spoke a VNets de hub de Virtual WAN en cada región, habilita el emparejamiento global de redes virtuales para la conectividad entre regiones que proporciona baja latencia a través de la red troncal de Azure, el tránsito de puerta de enlace configurado que permite que las VNets de spoke utilicen puertas de enlace de hub de Virtual WAN o de ExpressRoute sin desplegar puertas de enlace adicionales, reduciendo los costos y la complejidad. Además, se implementan grupos de seguridad de red en subredes de spoke que controlan el flujo de tráfico entre VNets emparejadas con acceso de privilegios mínimos.

• Optimización y supervisión del tráfico: Circuitos ExpressRoute configurados con marcas QoS que priorizan el tráfico de transacciones financieras sobre transferencias de datos masivas, habilitado Monitor de Conexión para el seguimiento de la latencia, pérdida de paquetes y disponibilidad para circuitos ExpressRoute y conexiones VPN, con alertas para degradación; se implementaron cuadernos de Azure Monitor que visualizan la topología de conectividad global mostrando conexiones activas, uso de ancho de banda y eventos de conmutación por error; líneas base establecidas para un rendimiento aceptable con alertas automatizadas para infracciones de umbral.

Resultado: Se ha logrado la conectividad privada para todas las transacciones financieras, cumpliendo PCI-DSS requisitos. ExpressRoute proporcionó una latencia baja coherente para el comercio en tiempo real. Virtual WAN redujo considerablemente la latencia de rama a centro de datos. Los empleados remotos se conectaron correctamente a través de vpn de punto a sitio con una autenticación mejorada. El emparejamiento global de VNet habilitó una recuperación ante desastres eficiente entre regiones. Optimización de costos lograda a través de la consolidación de Virtual WAN.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

• NIST SP 800-53 Rev.5: SC-7, SC-7(4), SC-8
• PCI-DSS v4: 1.2.1, 2.2.7, 4.2.1
• Cis Controls v8.1: 12.8, 13.8
• NIST CSF v2.0: PR. AC-05, PR. DS-02
• ISO 27001:2022: A.8.21, A.8.22, A.5.14
• SOC 2: CC6.6, CC6.7

NS-10: Garantizar la seguridad del sistema de nombres de dominio (DNS)

Principio de seguridad

Asegúrese de que la configuración de seguridad del sistema de nombres de dominio (DNS) protege contra los riesgos conocidos:

• Use servicios DNS autoritativos y recursivos de confianza en el entorno en la nube para asegurarse de que el cliente (como sistemas operativos y aplicaciones) recibe el resultado de resolución correcto.
• Separe la resolución DNS pública y privada para que el proceso de resolución dns de la red privada se pueda aislar de la red pública.
• Asegúrese de que la estrategia de seguridad de DNS también incluya mitigaciones contra ataques comunes, como DNS en suspensión, ataques de amplificación de DNS, envenenamiento de DNS y suplantación de DNS, etc.

Riesgo para mitigar

Los actores de amenazas atacan servicios DNS o aprovechan los servicios DNS vulnerables para poner en peligro las aplicaciones y redirigir el tráfico.

• Suplantación o intoxicación de DNS: Los adversarios falsifican respuestas DNS o memorias caché de resolución dañadas (por ejemplo, ataque Kaminsky) para redirigir a los clientes a servidores malintencionados, lo que permite la suplantación de identidad (phishing) o la interceptación de datos.
• Ataques de amplificación de DNS: Los atacantes aprovechan los servidores DNS mal configurados para amplificar el tráfico DDoS (por ejemplo, una consulta de 60 bytes que produce una respuesta de 4000 bytes), lo que sobrecarga las redes de destino.
• Explotación de DNS pendiente: Los registros pendientes (por ejemplo, CNAME obsoletos) permiten a los adversarios secuestrar recursos retirados, redireccionando el tráfico a puntos de conexión malintencionados para suplantación de identidad o malware.
• Filtración de datos a través de la tunelización DNS: Los actores malintencionados codifican los datos en las consultas DNS (por ejemplo, data.exfil.evil.com) para filtrar información confidencial encubierta, pasando firewalls.
• Entrega de phishing/malware: Los resolutores comprometidos redirigen dominios legítimos a direcciones IP controladas por atacantes, entregando páginas de suplantación de identidad o malware a clientes desprevenidos.

MITRE ATT&CK

• Comando y control (TA0011): Use la tunelización DNS para codificar comandos C2 en consultas (por ejemplo, data.exfil.evil.com) o resoluciones de suplantación de identidad para conectarse a servidores malintencionados (por ejemplo, T1071.004 - Protocolo de capa de aplicación: DNS).
• Colección (TA0009): Recopile datos mediante la suplantación de DNS para redirigir a los usuarios a sitios de phishing o exfiltrar datos a través de la tunelización (por ejemplo, T1040 - Interceptación de red).
• Impacto (TA0040): Ataques de amplificación de DNS, envío de consultas pequeñas para generar respuestas grandes, interrumpir la disponibilidad del servicio (por ejemplo, T1498.002 - Denegación de servicio de red: Amplificación de reflexión).
• Acceso inicial (TA0001): Aprovechar los registros DNS pendientes o las resoluciones suplantadas para entregar malware/phishing, para obtener acceso a los sistemas (por ejemplo, T1190 - Explotar aplicación expuesta al público).

NS-10.1 Uso del servicio DNS de confianza

Use servicios DNS de confianza para asegurarse de que los clientes reciben resultados de resolución correctos y protegen contra ataques basados en DNS. Azure proporciona el servicio DNS recursivo en 168.63.129.16 (normalmente asignado a través de DHCP o preconfigurado) para la resolución DNS de carga de trabajo en el nivel de sistema operativo o aplicación. Como alternativa, use servidores DNS externos de confianza. En el caso de las organizaciones que hospedan sus propios dominios, Azure DNS proporciona hospedaje DNS autoritativo confiable. Las organizaciones que crean servidores DNS personalizados deben seguir las directrices de implementación segura de NIST SP 800-81 Rev. 3:

• Use DNS recursivo de Azure o DNS externo de confianza: Configure las cargas de trabajo para usar DNS recursivo de Azure (168.63.129.16) o servidores DNS externos de confianza en sistemas operativos de máquina virtual o configuración dns de aplicación para garantizar una resolución confiable de nombres.

• Permitir Azure DNS en reglas de firewall: Agregue 168.63.129.16 al firewall y a las listas de autorización del grupo de seguridad de red para garantizar el funcionamiento adecuado de DNS para los recursos de Azure.

• Alojar dominios en Azure DNS: Use Azure DNS para alojar la resolución de dominios para las necesidades de DNS autoritativo, proporcionando un hospedaje DNS confiable y escalable (nota: Azure DNS no ofrece el servicio de registro de dominio).

• Siga las directrices de implementación de DNS seguras: Si crea servidores DNS personalizados, siga la Guía de implementación del sistema de nombres de dominio seguro (DNS) de NIST SP 800-81 Rev. 3 para implementar los procedimientos recomendados de seguridad.

NS-10.2 Uso de DNS privado en la red virtual

Use Dns privado de Azure para establecer zonas DNS privadas en las que la resolución DNS permanece dentro de la red virtual, lo que impide que las consultas DNS atraviesan redes públicas. Esto es esencial para las configuraciones de punto de conexión privado, donde las zonas DNS privadas invalidan la resolución DNS pública para enrutar el tráfico de forma privada a los servicios de Azure. Las soluciones DNS personalizadas pueden restringir aún más la resolución a solo orígenes de confianza, lo que mejora la seguridad de las cargas de trabajo privadas:

• Despliega DNS privado de Azure para la resolución privada: Usa DNS privado de Azure para crear zonas DNS privadas que mantengan la resolución DNS dentro de la red virtual y garantizan que las consultas nunca abandonen el límite de la red.

• Configuración de DNS privado para puntos de conexión privados: Configure zonas DNS privadas para puntos de conexión privados para invalidar la resolución DNS pública y asegurarse de que los clientes resuelven los FQDN del punto de conexión privado en direcciones IP privadas dentro de la red virtual.

• Implemente DNS personalizado para la resolución restringida: Utilice servidores DNS personalizados para restringir la resolución DNS de forma que solo se permitan fuentes de resolución de confianza para sus clientes, brindando un control adicional sobre la seguridad de la resolución de nombres.

NS-10.3 Usar Defender para DNS para protección avanzada

Use Microsoft Defender para DNS para detectar y alertar sobre amenazas de seguridad avanzadas basadas en DNS, incluida la filtración de datos a través de túnel DNS, comunicación de comando y control, interacciones de dominio malintencionadas (phishing, minería de cifrado) y ataques DNS que implican solucionadores malintencionados. La protección de Defender para DNS ahora se incluye en el plan de Defender para servidores. Además, use Microsoft Defender para App Service para detectar registros DNS pendientes que podrían habilitar ataques de adquisición de subdominios al retirar sitios web:

• Habilitación de la protección de Defender para DNS: Use Microsoft Defender para DNS (incluido en el plan de Defender para servidores) para supervisar y alertar sobre la actividad DNS sospechosa, incluida la filtración de datos a través de la tunelización dns, la comunicación de comandos y controles de malware y las interacciones con dominios malintencionados.

• Supervisión de la actividad DNS malintencionada: Configure alertas para detectar la comunicación con solucionadores DNS malintencionados y ataques DNS que podrían poner en peligro la seguridad de la carga de trabajo o la disponibilidad del servicio DNS.

• Detectar registros DNS pendientes: Use Microsoft Defender para App Service para identificar los registros DNS pendientes al retirar sitios web de App Service, lo que impide ataques de adquisición de subdominios asegurándose de que los dominios personalizados se quitan de los registradores DNS.

Ejemplo de implementación

Desafiar: Una empresa necesitaba una seguridad DNS completa que abarcase servicios de resolución de confianza, DNS de red privada para recursos internos y detección avanzada de amenazas en toda la infraestructura de nube híbrida.

Enfoque de solución:

• Implementado el DNS recursivo de Azure (168.63.129.16) para todas las cargas de trabajo de máquinas virtuales de Azure, con reglas de NSG que permiten el tráfico DNS.
• Zonas autoritativas hospedadas en Azure DNS para la resolución de dominio público con distribución geográfica
• Se han implementado zonas DNS privadas de Azure para la resolución de puntos de conexión privados (privatelink.database.windows.net, privatelink.blob.core.windows.net) vinculadas a redes virtuales de producción.
• La integración de DNS privado configurada garantiza que los FQDN del punto de conexión privado se resuelvan en direcciones IP privadas (por ejemplo, sqlserver.database.windows.net → 10.0.2.4)
• Habilitado Microsoft Defender para DNS a través del Plan para Defender para servidores, para supervisar la tunelización DNS, la comunicación C2 y las interacciones con dominios malintencionados.
• Se ha implementado Defender para App Service para detectar registros DNS colgantes durante el desmantelamiento del sitio web

Resultado: La implementación de seguridad de DNS garantiza una resolución de nombres confiable para cargas de trabajo en la nube, a la vez que mantiene la privacidad de los recursos internos. Las zonas DNS privadas impedían que las consultas confidenciales atravesaran redes públicas, mientras que Defender para DNS proporcionaba visibilidad sobre amenazas basadas en DNS, incluidos los intentos de filtración de datos y la actividad de comando y control. La solución eliminó los riesgos de adquisición de subdominios mediante la detección automatizada de DNS pendiente durante los cambios en el ciclo de vida de los recursos.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

• NIST SP 800-53 Rev.5: SC-7, SI-4, SI-4(4), SI-4(5)
• PCI-DSS v4: 11.5.1, 12.10.1
• Cis Controls v8.1: 8.5, 13.6, 13.8
• NIST CSF v2.0: DE. CM-01, DE. CM-04, DE. AE-02
• ISO 27001:2022: A.8.16, A.8.22, A.5.24
• SOC 2: CC6.1, CC7.2, CC7.3