Diferencias entre los grupos de seguridad de AWS y el cortafuegos virtual de Palo Alto Networks
Resolution
Introducción
A medida que las empresas continúan abrazando los recursos de la nube pública, es importante mantener un ojo atento en la obtención de aplicaciones y datos. No porque los datos corporativos potencialmente residen en un centro de datos que no sea el suyo propio, sino porque siguen siendo datos corporativos, independientemente de su configuración regional. Las organizaciones de seguridad dentro de la empresa deberán ajustarse a las aplicaciones corporativas y a los datos que residen en cualquier lugar y ser accesibles desde cualquier lugar y potencialmente desde cualquier dispositivo. Esto erosiona eficazmente el modelo perimetral estándar para la seguridad. El perímetro está ahora alrededor de las aplicaciones y los datos, no importa dónde residen.
Esta transición requerirá una comprensión de lo que las características de seguridad pueden ser ofrecidas del vendedor de la nube pública, e igualmente importante-lo que no se ofrece. Las ofertas de seguridad integradas dentro de la nube pública no están a la par con las que ofrece la plataforma de seguridad de Palo Alto Networks. Este documento destaca algunas de esas diferencias – específicamente para AWS pero los mismos conceptos se aplican a Azure. También se muestra cómo el mismo enfoque de plataforma que se toma dentro del centro de datos privado debe extenderse a la nube pública, o dondequiera que sus aplicaciones y datos sean accesibles.
Una comparación entre los dos revela fácilmente que las características de seguridad incorporadas son en realidad, sin comparación con el enfoque de plataforma de Palo Alto Networks. De hecho, son suplementarios y deben desplegarse juntos. Para AWS, la seguridad incorporada no se puede deshabilitar y es un requisito. Sin embargo, dejar su postura de seguridad con sólo el motor incorporado es algo que ni siquiera AWS recomienda[1].
Comparación
La tabla siguiente no es exhaustiva, pero destaca algunas de las características que no se proporcionan como parte del motor de seguridad incorporado dentro de la nube pública de AWS. El final de la tabla enumera algunos de los controles de seguridad específicos de AWS. Es importante recordar que la decisión para las organizaciones no es "una u otra", sino utilizar ambos enfoques para una postura integral de seguridad.
Características clave | PAN | AWS |
Servidor de seguridad |
|
|
Miles de aplicaciones de visibilidad y control; capacidad para crear aplicaciones personalizadas; capacidad de gestionar el tráfico desconocido basándose en la política | X |
|
Identificación y control de usuarios: VPNs, controladores WLAN, portal cautivo, proxies, Active Directory, eDirectory, Exchange, servicios de Terminal Server, análisis de syslog, API XML | X |
|
Desencriptación e inspección de SSL granular (entrante y saliente); control SSH por directiva (entrante y saliente) | X |
|
Networking: enrutamiento dinámico (RIP, OSPF, BGP, multiprotocolo BGP), DHCP, DNS, NAT, redistribución de rutas, ECMP, LLDP, BFD, inspección de contenido de túneles | X |
|
QoS: configuración de tráfico basada en políticas (prioridad, garantizada, máxima) por aplicación, por usuario, por túnel, basándose en la clasificación DSCP | X |
|
Segmentación de la red y protección de zonas basadas en zonas; Protección de dos contra inundaciones de nuevas sesiones | X |
|
Prevención de amenazas |
|
|
La prevención de una gran variedad de amenazas, incluyendo vulnerabilidades, malware y redes de bots | X |
|
Bloqueo de malware polimórfico centrándose en la carga útil, en lugar de hash o nombre de archivo | X |
|
Protecciones actualizadas automáticamente cada cinco minutos con Wildfire | X |
|
Protección avanzada contra malware (WildFire) |
|
|
Análisis dinámico: detonación de archivos en un entorno virtual resistente a la evasión y construido a la medida, lo que permite la detección de malware y vulnerabilidades de día cero | X |
|
Análisis estático: detección de malware y hazañas que intentan evadir el análisis dinámico; identificación instantánea de variantes de malware existente | X |
|
Aprendizaje de la máquina: extracción de miles de características únicas de cada archivo, la formación de un clasificador predictivo máquina de aprendizaje para identificar nuevos malware y hazañas | X |
|
Análisis de metales desnudos: amenazas evasivas enviadas automáticamente a un entorno de hardware real para la detonación, eliminando por completo la capacidad de un adversario para implementar el análisis anti-VM | X |
|
Actualizaciones automáticas de firmas cada cinco minutos para malware de día cero y vulnerabilidades descubiertas por cualquier suscriptor de Wildfire | X |
|
Servicio inteligente de amenazas contextuales (enfoque automático) |
|
|
Contexto en torno a ataques, adversarios y campañas, incluidas las industrias específicas | X |
|
Análisis acelerado y esfuerzos de respuesta, incluyendo alertas priorizadas para las amenazas más críticas | X |
|
Filtrado de URL |
|
|
Protección contra sitios maliciosos que exponen su gente y datos al malware y los kits de explotación | X |
|
Protección contra el phishing de credenciales inspeccionando páginas web para determinar si el contenido y el propósito son maliciosos en la naturaleza. Categorías de URL personalizadas, alertas personalizables y páginas de notificación. | X |
|
Filtrado de archivos y datos |
|
|
Control bidireccional sobre la transferencia no autorizada de tipos de archivo y números de seguro social, números de tarjeta de crédito y patrones de datos personalizados | X |
|
Seguridad móvil (global Protect) |
|
|
VPN de acceso remoto (SSL, IPSec, cliente) y prevención de amenazas móviles y aplicación de políticas basadas en aplicaciones, usuarios, contenido, dispositivo y estado del dispositivo | X |
|
BYOD: VPN de nivel de aplicación para la privacidad del usuario | X |
|
Herramientas de gestión y visibilidad (gestión de políticas centralizadas) |
|
|
Control intuitivo de políticas con aplicaciones, usuarios, amenazas, protección avanzada de malware, URL, tipos de archivos, patrones de datos – todo en la misma política | X |
|
Información sobre el tráfico y las amenazas con el centro de comando de aplicaciones (ACC), informes totalmente personalizables | X |
|
Registro agregado y correlación de eventos | X |
|
Administración consistente de todo el hardware y de todas las series VM, control de acceso basado en roles, grupos de dispositivos lógicos y jerárquicos y plantillas | X |
|
GUI, CLI, API REST basada en XML | X |
|
Etiquetado dinámico para automatización de directivas |
|
|
Uso de políticas de filtrado granular combinadas con etiquetado automático para mover hosts comprometidos entre grupos de seguridad. ES DECIR poner en cuarentena un host si se ve el tráfico de comandos y controles, por ejemplo. | X |
|
Uso de políticas de etiquetado para enviar automáticamente datos relevantes a un sistema de tickets en caso de infracción de seguridad | X |
|
Funciones generales |
|
|
Seguridad basada en IP/puerto/protocolo | X | X |
Rangos de puertos utilizados en la Directiva | X | X |
Origen y/o destino dentro de la Directiva (Nota: AWS separa el entrante y el saliente como reglas separadas) | X | X |
Reglas basadas en CIDR | X | X |
Características similares a las ACL dentro de una directiva | X | X |
Seguridad aplicada después de que el tráfico entre VPC | X | X |
Drop vs deNegar la distinción dentro de una política | X |
|
Características específicas de AWS |
|
|
Uso de un grupo de seguridad AWS como origen/destino. * Nota: una alternativa de Palo Alto Networks puede ser utilizar IPSec entre VPC para controlar el tráfico. | * | X |
Seguridad aplicada antes de que el tráfico entre VPC. * Nota: esto sería una característica suplementaria usada conjuntamente con los cortafuegos virtuales de la red de palo alto. |
| X |
Efectos del uso de la seguridad de sólo AWS
Utilizar sólo los grupos de seguridad y las ACL disponibles dentro de AWS sería tomar su postura de seguridad 25 años atrás en términos de protección. Esto se debe al enfoque céntrico del puerto/protocolo de los grupos de seguridad. Hubo un tiempo en que el uso de este método era todo lo que se requiere. Cuando el tráfico HTTP sólo se veía en el puerto TCP 80, o cuando el tráfico Telnet sólo se veía en el puerto TCP 23, etc. Esto simplemente ya no es el caso – y no ha sido el caso durante muchos años. El tráfico de aplicaciones no sólo reside en una gama más amplia de puertos, pero estos puertos a menudo pueden ser dinámicos en la naturaleza que cubren un espectro enorme. Esto hace que sea imposible crear una política de seguridad basada en los intervalos de puertos o puertos, ya que esto abre la puerta al malware que puede utilizar estos mismos puertos bien conocidos.
Otro problema con la utilización estricta de la seguridad basada en el puerto/protocolo es que muchas aplicaciones potencialmente utilizan los mismos intervalos de puertos. La seguridad moderna requiere una manera de distinguir entre las aplicaciones, independientemente del puerto o protocolo en uso. La siguiente captura de pantalla revela la seguridad basada en el puerto/protocolo incorporada al modelo AWS:
Observe la columna "type" en el ejemplo. Esto no se debe confundir con el reconocimiento de la aplicación. Esto es simplemente una forma de elegir una aplicación de una lista sólo para que el puerto estándar se inserte en la regla real. Para realizar la identificación de la aplicación, independientemente del puerto o protocolo, se requiere una inspección profunda de los paquetes de sesión. Sin embargo, no es así como funciona un motor basado en un puerto/protocolo.
Si los datos corporativos viven dentro de un centro de datos corporativo o de la nube pública, es esencial reducir la superficie de ataque dentro de la postura de seguridad. Por las aplicaciones de listas blancas que se requieren para el negocio y la eliminación de aplicaciones desconocidas, la superficie de ataque puede reducirse sustancialmente. Cuando se combina con restringir a los usuarios a acceder sólo a las aplicaciones/datos necesarios basándose en el rol o el grupo, por ejemplo, la superficie de ataque se reduce aún más. Esto requiere las características avanzadas del cortafuegos de nueva generación de Palo Alto Networks. Esto es cierto independientemente de dónde residen los datos.
¿Dónde entran en escena las características de seguridad incorporadas de AWS? Se utilizan como una capa suplementaria de seguridad, en lugar de una sustitución de la moderna inspección de tráfico. Por ejemplo, se podría utilizar la función de grupos de seguridad en el perímetro (exterior) del VPC para soltar el tráfico de rangos de IP específicos (por ejemplo, direcciones geo-basadas o mal-IP, etc.). Otro caso de uso potencial es controlar la gestión del VPC o controlar el tráfico entre los VPC. El requisito para las características avanzadas de la inspección todavía existe fuera del uso de los componentes incorporados de la seguridad de AWS.
Resumen
En Resumen, hay dos preguntas que hacer cuando se trata de un enfoque "uno o el otro" para la seguridad de las nubes públicas.
¿Estaría cómodo abandonando su NGFWs en sedes y sucursales protegiendo a los usuarios y a los datos corporativos (perímetro y centro de datos) y reemplazarlo por completo con un cortafuegos AWS (grupos de seguridad y ACL)?
Si la respuesta es "no", ¿tiene sentido utilizar sólo la seguridad de AWS para proteger sus datos corporativos dentro de la nube pública?
Los dos componentes son suplementarios y se deben desplegar juntos al igual que se utilizan varias capas en las oficinas centrales y sucursales.
Referencias y notas
[1] AWS Shared Response Model : https://AWS.Amazon.com/Compliance/Shared-Responsibility-Model/
¿Cuál es la mejor práctica para implementar el cortafuegos de la serie VM de AWS y Palo Alto Networks en la nube pública?
En el VPC AWS, los grupos de seguridad y las ACL de red controlan el tráfico entrante y saliente; los grupos de seguridad regulan el acceso a la instancia de EC2, mientras que las ACL de red regulan el acceso a la subred. Debido a que está implementando el cortafuegos de la serie VM de Palo Alto Networks, establezca reglas más permisivas en sus grupos de seguridad y ACL de red y permita que el cortafuegos habilite las aplicaciones en el VPC mientras inspecciona las sesiones de malware y actividades maliciosas.
Los grupos de seguridad de AWS utilizan puerto/protocolo:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_Network_and_Security.html
"Puede utilizar grupos de seguridad para controlar quién puede acceder a sus instancias. Estos son análogos a un cortafuegos de red entrante que permite especificar los intervalos de protocolos, puertos y IP de origen que pueden llegar a sus instancias. Puede crear varios grupos de seguridad y asignar reglas diferentes a cada grupo. A continuación, puede asignar cada instancia a uno o varios grupos de seguridad, y usamos las reglas para determinar qué tráfico se permite llegar a la instancia. Puede configurar un grupo de seguridad para que sólo las direcciones IP específicas o los grupos de seguridad específicos tengan acceso a la instancia. "
http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-network-security.html
"Un grupo de seguridad actúa como un cortafuegos virtual que controla el tráfico de una o más instancias. Al iniciar una instancia, se asocian uno o más grupos de seguridad con la instancia. Se agregan reglas a cada grupo de seguridad que permiten el tráfico desde o hacia sus instancias asociadas. "
http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-network-security.html
"Si tiene requisitos que no cumplen los grupos de seguridad, puede mantener su propio cortafuegos en cualquiera de sus instancias además de utilizar grupos de seguridad".
Los grupos de seguridad y las ACL combinados se refieren a un "Firewall" dentro de AWS:
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html
"Una lista de control de acceso a la red (ACL) es una capa opcional de seguridad para su VPC que actúa como un cortafuegos para controlar el tráfico dentro y fuera de una o más subredes. Puede configurar ACL de red con reglas similares a sus grupos de seguridad para agregar una capa adicional de seguridad al VPC. "
Los tipos de reglas de AWS se sustituyen simplemente por el puerto estándar utilizado típicamente por la aplicación:
Las reglas de salida de AWS siguen la misma sintaxis de Puerto/protocolo:
A continuación se muestra un ejemplo de la LCA de red predeterminada de AWS para un VPC que sólo admite IPv4:
Ejemplo de creación de ACL de AWS: