VMworld 2017 – AppDefense en profundidad para seguridad de aplicaciones

/, Cloud Computing, Lanzamiento, NSX, NSX, Software Defined Datacenter, vExpert, VMware, VMworld, vSphere, VXLAN/VMworld 2017 – AppDefense en profundidad para seguridad de aplicaciones
[Total: 7    Average: 2.7/5]

Una de las novedades que han sido anunciadas durante este VMworld 2017 en Las Vegas, es el lanzamiento de VMware AppDefense, una solucion de seguridad para aplicaciones conocida previamente como proyecto Goldilocks, que puede integrarse con NSX para proveer una solucion de seguridad a multiples capas en un SDDC.

El foco del team de seguridad de VMware es aprovechar las características de la infraestructura virtual (ESXi / NSX y otras parte del SDDC).  El objetivo es no pensar en la infraestructura virtual como otro elemento a proteger/asegurar, sino que verla como una herramienta para permitir una mejor postura de seguridad en el DC, aprovechando las ventajas de NSX y la microsegmentacion como una gran porción de dicha vision.

AppDefense es la siguiente generación en soluciones para crear una postura de seguridad de “Least Privileges” en el DC, enfocándonos en como manejamos y controlamos el comportamiento a nivel de Sistema Operativo guest y sus Aplicaciones, utilizando las funcionalidades del hypervisor para realizar guest introspection.


Cual es el foco de AppDefense?

Muchas soluciones, y buena parte de la inversion en seguridad se enfocan en detener la infiltración (Parte frontal del ataque), lo cual de por si es complejo, ya que de mil intentos que pueda hacer un atacante, basta que solo 1 sea exitoso para generar un daño importante en la infra. 

Por otro lado, no muchas compañías se enfocan en la inter-area del ataque, es decir en la protección contra extracción de datos y propagación del ataque.

Por un lado, NSX puede proveer microsegmentacion lo cual evita la propagación del ataque a nivel de Network, evitando movimiento lateral en el datacenter, lo cual es un mecanismo poderoso para la seguridad del DC.  El objetivo es continuar avanzando en limitar y evitar la parte de propagación y extracción de un ataque.

Con AppDefense lo que se busca es detener ciertos tipos de comportamientos que suceden en una VM.   Los comportamientos que se buscan detener son basicamente aquellos que impliquen una posible propagación de amenazas en el DC, además de obtener notificaciones inmediatas cuando una VM o App en el DC se esta comportando inapropiadamente, además de poder controlar dicho comportamiento, y potencialmente responder a ese comportamiento de una manera más completa.

Una de las razones por las que las personas no se enfocan en el area media del ataque, es que requiere mucho conocimiento en las aplicaciones e infraestructura.  Tipicamente las compañias revisan y analizan el trafico que se genera en el DC, tratando de aplicar controles de seguridad sobre los mismos.  Ellos encuentran algunos comportamientos conocidos clasificados como buenos (unos pocos) o malos (usualmente muchos más), y luego una gran area gris de comportamiento desconocido (sin saber si son buenos o malos).  Ante esto, la estrategia común del area de seguridad es tomar toda esa información y enviarla a algún agregador de logs y tener a un montón de personas tratando de averiguar si dicho comportamiento es bueno o malo.  El problema es la escala de la información a manejar, la mayoría de las organizaciones no tienen las personas, el tiempo y la energía necesaria para ir a través de toda esa información y analizarla, y aun si lo pudieran hacer, aun hay una buena chance de que puedan cometer errores o interpretar erróneamente ciertos comportamientos, y eso es potencialmente una brecha de seguridad que puede quedar abierta a posibles ataques.

Entonces el objetivo de VMware, es como clasificar mejor los comportamientos de las VM en el DC y reduce esta area gris tanto como podamos.   Ese es el foco de AppDefense, tratar de clasificar la información apropiadamente y asegurarnos de que estamos mirando la forma en que los sistemas se comportan.

La mayoría de las organizaciones se enfocan primero usualmente en las medidas menos importantes según Gartner (aunque importantes al fin y al cabo) como el AV para usuarios finales, lo cual debiera ser lo ultimo en la lista de prioridades de seguridad.

AppDefense se enfoca en las estrategias de protección Core, es decir:

  • Prevension de Exploits / Protección de memoría
  • Control de App
  • Monitoreo de integridad de sistemas.
  • Firewall de red, segmentación y visibilidad.
  • Gestion de configuraciones y vulnerabilidades / Hardening

Necesitamos enfocarnos en las App

El foco de AppDefense es tener entender el comportamiento de las app, y una vez que entendemos mejor el comportamiento de las app, podemos aplicar mejores controles alineados alrededor de las apps, pudiendo hacer un mejor trabajo aplicando la estrategia de “Least Privilege”.  Si sabes exactamente como una App se comporta, entonces se pueden aplicar reglas que controlen dicho comportamiento, o se puede intentar detectar y comprender cuando el comportamiento de una app se desvía de lo normal, lo cual podria implicar la existencia de alguna amenaza.

Una estrategia de “Least Privileges” se trata de asegurarse de que solo las personas apropiadas tienen acceso, con los permisos apropiados para cada uno, a los datos correctos cuando sea necesario.  Esto se consigue a través de algunas capas.

  • A nivel de la red, provisto por NSX con la microsegmentacion, para poder crear reglas de firewall y proveer “least privileges” a nivel de network.

  • A nivel de plano de datos también se ha hecho algun trabajo con NSX para contar con una buena postura de seguridad de la data en la infra.  No es el foco de AppDefense pero es bueno tenerlo en mente.  Se trata de proteger el flujo de datos, y asegurar que solo las personas correctas tienen acceso a esta información cuando sea necesaria.

  • A nivel de app para asegurar “least privileges” en la aplicación misma.  Incluso si se tiene un ambiente correctamente segmentado, con solo las VMs apropiados dentro de un segmento para una App, esto no necesariamente detiene la posibilidad de que un atacante de comprometer alguno de los puntos dentro de la App.  Por ejemplo, podría haber un Sistema Operativo sin parchar dentro de los limites de un segmento que un atacante podría aprovechar.  Podría haber una App con alguna vulnerabilidad que un atacante pueda aprovechar.  En muchos casos hay que abrir ciertos puertos legítimos para que una App funcione, y esto junto con las vulnerabilidades son comúnmente aprovechadas por los atacantes para obtener acceso a través de puertos “buenos” conocidos y superar las defensas de seguridad en la red.

Enfocarnos en las App, nos lleva entonces a necesitar una mejor postura de seguridad, buscando el comportamiento especifico de las App dentro de los limites de la microsegmentacion.

Por ejemplo, una herramienta de seguridad a nivel de datacenter podría demandar comunicarse con multiples dispositivos a través de la red, lo cual podría requerir una política muy permisiva para poder hablar con un muchas diferentes maquinas en el DC.  Para poder habilitar esto hay que abrir puertos, lo cual implica abrir agujeros en las politicas de micro-segmentacion para que la herramienta pueda funcionar apropiadamente.  Desafortunadamente cuando se abren estos puertos, ya no hay certeza de que solo la herramienta apropiada este utilizando dicho puerto.  En dicho punto, cualquier persona podría comenzar a utilizar ese puerto de manera potencialmente maliciosa.

Visibilidad de las App

Entonces el objetivo de AppDefense, es “mirar” como específicamente los dispositivos (VMs / App) se comportan y buscamos maneras de que al momento de detectar una desviación del comportamiento/estado “normal” podamos tomar una acción apropiada al respecto y controlar dicho comportamiento.

La idea es entender el estado “normal” de las app, y eso lo logramos aprovechando la posición única de la capa de virtualization para tener una mejor comprension del estado de la App, y podamos pre-programar reglas sobre como la App debiera comportarse.

Apalancando el hipervisor y otras herramientas, AppDefense permite determinar el estado “esperado” de la app, es decir el estado en el cual fue configurado o provisionado, y también mirar el estado “runtime” de la App, utilizando el hipervisor para determinar como la App se esta comportando realmente

Si juntamos esto, podemos tener una mejor visibilidad de la forma en que las app se están comportando, y podemos usar esto para  crear perfiles de comportamiento para las app, y poder crear reglas de bloqueo de seguridad para las app

Isolation

Esto se logra muy bien con NSX y Distributed Firewall a nivel de red, de manera que el Firewall aplica las reglas muy cerca de las VM que intentamos proteger.

Podemos lograr el mismo nivel de aislamiento con AppDefense, usando el hipervisor como una herramienta de introspección sobre el comportamiento del guest.  Isolation nos permite esencialmente correr herramientas de seguridad con un alto contexto sobre el guest, mientras que nos mantenemos fuera de la zona de ataque (fuera del endpoint donde podría estar ubicado el atacante).  El poder utilizar estas capaz de aislación es una tremenda ventaja cuando trabajamos en un ambiente virtualizado.

Automatizacion

La ultima parte es una muy importante en la respuesta de las defensas de seguridad, y es la habilidad de utilizar automatización, ya que cuando se detecte que el comportamiento de una VM sea anormal, vamos a querer tomar alguna acción en respuesta. Podríamos querer cambiar el perfil de seguridad para permitir un análisis forense de la VM, o quizás se quiera realizar un logging adicional o una captura completa de paquetes de manera de hacer algún análisis offline.  Todo esto es lo que típicamente los teams de seguridad deben realizar para poder investigar, manejar y remediar estos ataques, algo que usualmente no es fácil de realizar con herramientas tradicionales.   Esto usualmente requiere cambios en la infra, mucho trabajo manual de cambios en las configuraciones de reglas de seguridad, todo lo cual crea inflexibilidad para los equipos de seguridad.

Con automatización, NSX y AppDefense, lo que hacemos es cambiar la postura de seguridad de una VM en respuesta a un comportamiento anormal.  De manera que cuando empezamos ver que una VM comience a comportarse anormalmente, AppDefense puede llamar a un conjunto de acciones de respuesta pre-configuradas, utilizando las capacidades de orquestación de NSX para poder realizar operaciones como habilitar captura de paquetes o poner la VM en una zona de cuarentena con medidas extremas de seguridad.  La idea es utilizar las capacidades de automatización del SDDC para orquestar la aplicación de políticas de seguridad


Cambio de paradigma

Lo que se busca específicamente con AppDefense, es que cuando comenzamos a mirar como asegurar cosas en la capa de App, nos movamos desde el antiguo modo de asegurar el comportamiento de las App que esta basado básicamente en tratar de detectar toda la actividad maliciosa conocida en una VM o App.  El desafío es que los atacantes están siempre cambiando de objetivo, y mejorando sus técnicas, yendo siempre un paso adelante con nuevas metodologías para superar las defensas de seguridad.   Usualmente nos enfocamos en detectar comportamiento malicioso.

La idea es cambiar el foco a uno en que podamos ver mejor como las App debieran comportarse y luego usar el hipervisor para continuamente vigilar dicho comportamiento y asegurarse que no nos desviamos de lo esperado.  El desafío es que es difícil tener una buena comprensión sobre como la VM y las App debiera comportarse, y los fabricantes de soluciones de seguridad de terceros usualmente solo quieren crear modelos genéricos y aplicarlo a cada una de las VM y cada uno de los tipos de App sin distinción entre ellas.

Entonces en vez de utilizar un modelo genérico que determina lo que es bueno o malo, nos concentramos en poder determinar cuando el comportamiento se esta desviando de lo que se determina como normal.  Para esto tenemos que tener una buena comprensión y visibilidad de nuestras App y de la infraestructura, de lo contrario tampoco lo podremos lograr.


AppDefense y la estrategia “Least Privilege”

 

AppDefense esta construido a través de 3 Modulos. 

  • El primero es el que nos permite definir el Estado Esperado (Intended State)
  • El Segundo es como controlamos y monitoreamos las VM y App para poder detectar comportamiento anormal, utilizando el hypervisor para una alta introspección en el guest y a través de este evaluar el comportamiento.
  • El tercer modulo es el de remediación, como podemos re-configurar o cambiar el ambiente apropiadamente

A traves de estos modulos, AppDefense nos presenta una serie de caracteristicas escenciales como producto:

  • Application Control: Se provee una vision completa de como luce una App, como ha sido configurada, y la infraestructura sobre la cual la App está corriendo, para luego utilizar toda esta información para determinar el comportamiento esperado de la App (procesos corriendo, comunicaciones, interacciones con el Sistema Operativo).   A partir de aquí podemos crear reglas que serán aplicadas durante el monitoreo del comportamiento de las VM y App.
  • Detección de anomalias y respuestas:  Podemos activar respuestas automatizadas una vez que se detecte un comportamiento anormal, o simplemente generar una notificación para el equipo de seguridad.  La activación de respuestas también puede ser manual, donde luego de una notificación el equipo de seguridad debe activar manualmente la acción configurada como respuesta al comportamiento anormal.
  • Análisis de procesos: Si miramos la habilidad de evaluar si se esta produciendo un comportamiento anormal , es decir si tenemos un estado distinto al Intended State (estado esperado), la primera pregunta que se hacen los teams de seguridad es si la VM se esta comportando anormalmente por un cambio legitimo en las App, o se comporta anormalmente por algo malicioso que se encuentra corriendo en la plataforma de lo cual debiéramos estar conscientes.
    Cuando comenzamos a ver una anomalía en el comportamiento, no se puede simplemente calcular un hash de los archivos en disco o algún otro metodo de clasificar (score) la amenaza, como el uso de firmas de antivirus.  Los atacantes se están volviendo mejores en superar las barreras de controles tradicionales mediante el calculo de hash o firmas de antivirus.  De hecho, muchos de los atacantes están utilizando técnicas que podemos denominar Ataques “in-memory”, donde tratan de manipular lo que esta corriendo específicamente en memoria de la VM después de que el Antivirus ha permitido la ejecución del archivo
    Así que lo que hacemos después de detectar una anomalía en el comportamiento, es ejecutar un analizador de procesos “in-memory”.  AppDefense además tiene la habilidad de proveer Snapshots “in-memory” de los procesos que se están creando y están causando las anomalías. 
    Lo que hacemos con el Process Analyzer  es analizar específicamente lo que está corriendo en memoria al momento en que la anomalía se presenta, entregando información de todas las amenazas potenciales y actividades sospechosas que ese proceso esta mostrando mientras se ejecuta en memoria.
  • Remediacion orquestadaUtilizando AppDefense y/o NSX, donde podemos crear workflows de respuesta, generar snapshots en la VM, ponerlas en cuarentena.   Podemos enlazar las Security Policies de NSX con las respuestas pre-configuradas en AppDefense al momento de detectar una anomalía.

 

Obtener el estado esperado

Podemos proveer todas las funcionalidad para vigilar y evaluar el comportamiento en las VM y Apps, pero es difícil siempre poder definir cual sería el comportamiento de una App en estado normal, y se puede volver una pesadilla operacional definir todos los comportamientos posibles de una App. VMware ha puesto mucho esfuerzo en AppDefense de manera de facilitar la definición de lo que implica un Intended State (estado esperado) sin tanto esfuerzo ni complicaciones adicionales.

AppDefense tiene 3 metodos para poder evaluar y determinar el Intended State o Estado Esperado de una App:

  • Infrastructure Events: El objetivo aquí es apalancar el conocimiento que ya existe en la mayoría de los DC altamente automatizados, especialmente cuando contamos con un SDDC donde la automatización es un componente clave.  Esencialmente los equipos de infraestructura y de aplicaciones ya tienen una buena comprension y perfiles de como las maquinas se comportan, como las VM son provisionadas a partir de blueprints, etc.
    Aquí tenemos herramientas como vRA, Puppet o Chef, que nos permite crear perfiles o blueprints de VMs, por lo que podemos definir que paquetes debieran ser desplegados en una VM especifica, incluyendo especificaciones de comunicación. De hecho podemos hacer un seguimiento de los cambios de configuración de las App a través de las mismas herramientas.  Por ejemplo podremos saber si la VM tiene instalado determinada app, como Tomcat o SQL, que version de la aplicacion se ha instalado, que comportamiento tiene a nivel de comunicaciones, etc.
    Así que podemos obtener el Intended State desde herramientas de este tipo, en integración también con vCenter y/o NSX, lo que permitirá tener un mayor detalle respecto a la configuración de la VM y sus Apps.
  • Developer Workflows permite automatizar cambios a las App desde los equipos de desarrollo, y que estos cambios puedan ser potencialmente reconocidos posteriormente como parte del comportamiento esperado de la VM.  Esto es especialmente util con la realidad actual de las técnicas aceleradas de desarrollo y constante cambio en las aplicaciones.
    Por ejemplo, si determinamos el comportamiento normal de una App, pero esta App es constantemente actualizada por el equipo de desarrollo, rápidamente la definición del estado normal de la App puede quedar obsoleta.  Esto podría provocar una cantidad importante de trabajo sobre los teams de seguridad para mantener actualizados los perfiles de comportamiento de cada App.  La idea aquí es proveer cierta inteligencia para poder entender los cambios producidos sobre una App producto de los cambios generados por el equipo de Desarrollo de una manera mas automatizada.
  • Runtime Behavior (o Discovery Mode): Si no tenemos ningún conocimiento del perfil de comportamiento de nuestras aplicaciones, y no contamos con ninguna herramienta de automatización o de provisionamiento en la infraestructura, como el uso de blueprints con vRA, entonces lo que se debe realizar es una fase de descubrimiento, obteniendo información a partir del estado de ejecución de la VM y sus App, el cual posteriormente debe ser validado y aprobado por el team de seguridad.  Este perfilamiento inicial lo realizara el hypervisor, basado en el comportamiento que va detectando en cada App, y puede tardar algunos dias en poder tener informacion suficientemente detallada para poder determinar el Intended State de cada una de las App.
    Esto es para ambientes brownfield, donde las App ya se encuentran desplegadas,

Apalancando la aislación

Hasta ahora, los administradores de seguridad han sido forzados a elegir entre productos de seguridad que ofrecen alto contexto y baja aislación, o bajo contexto y alta aislación.

  • Un alto contexto de seguridad provee un nivel más profundo de conocimiento del tipo de trafico y los patrones.
    • La integracion en el Sistema Operativo y Apps permite un mayor grado de contexto.
    • Tambien pone los controles de seguridad en la zona de ataque.  Cual es la primera cosa que un malware hace cuando llega? Deshabilita la solución anti-malware o antivirus.
  • Una alta aislación significa que el control de seguridad se encuentra fuera de la zona de ataque, con una gestión centralizada.
    • Controles basados en red evitan el problema de estar dentro de la zona de ataque.  Pero la mayor parte del tiempo, ellos no tienen una idea acabada de lo que esta pasando con las App, procesos, archivos y usuarios.
  • Productos tradicionales de DC tienen una relacion inversa entre contexto y aislación por lo que se debe elegir
    • Se quiere control con mayor informacion (contexto) o se quiere control efectivo (aislacion)?
    • Claramente se necesitan ambos, y la capa de virtualizacion (hypervisor) esta en una posicion unica para proveer visibilidad en el guest desde una posición de confianza aislado de la zona de ataque. En otras palabras, provee conexto y aislación.

Con AppDefense entonces se apalanca el hypervisor como una forma de vigilar el comportamiento de las App directamente sin estar dentro del Guest (alta aislación), creando además una zona protegida en la memoria (Protective Memory) de la VM guest donde ubicar los controles de seguridad que necesitemos dentro de la VM.

Para detener ciertos comportamientos, el hypervisor utilizará una porción de memoria como Protective Memory dentro del guest donde solo podremos poner controles de seguridad, y cualquiera que intente meterse con estos controles de seguridad o manipularlos, provocará el envío de una notificación inmediatamente, ademas de opcionalmente generar alguna acción.  Basta con que se modifique un bit en la Protective Memory para que se activen las notificaciones y/o acciones

Remediacion Automatica

La remediación automatica con AppDefense permite activar ciertas respuestas (automaticas o manuales) una vez que se ha identificado un comportamiento anormal en una VM o App.  Estas operaciones pueden ir desde bloquear el trafico generado por el comportamiento anormal, crear una notificación, o incluso suspender la VM completa.  AppDefense si bien no depende de NSX para funcionar, se espera que con el futuro lanzamiento de NSX 6.4 exista una integración con los Security Tags y las Security Policies (Service Composer), permitiendo poner la VM en una zona de cuarentena dentro de NSX

 


AppDefense en acción

Al momento de ingresar al Dashboard de AppDefense podremos ver cuantas VM se encuentran protegidas, cuantas no cuentan con protección, y cuantas se encuentran en descubrimiento (in Discovery).  Estas ultimas son VM sobre las cuales se está aun averiguando cual es su comportamiento “normal”, antes de que pasen a un estado “Protegido” en el cual se va a a comparar el Comportamiento “runtime” o real, con el comportamiento “normal” definido previamente.

Al momento de definir los comportamientos, se pueden configurar por TIER de aplicaciones, de manera que se puede aumentar el numero de VM es uno de los Tiers, por ejemplo en el tier de App para balanceo de carga, y que se le aplique el mismo perfil de comportamiento si consideramos que todas las VM de un mismo tier debieran ser homogéneas.

 

Por ejemplo, estamos viendo aquí el App-Tier que cuenta con 1 VM y 60 comportamientos permitidos, y 4 reglas.  Si revisamos uno de los comportamientos permitidos, es el del proceso Python.exe que, entre otros, tiene permitido comunicarse por el puerto TCP 1433 (SQL) con una IP en particular (la de la VM de BD), y con la DB-Tier, utilizando el Tier como una abstracción que puede ser utilizada como parte de la configuración de los comportamientos de la VM.  Esto permite que si la VM con la BD cambia de IP, el comportamiento no necesita ser modificado en AppDefense, ya que el comportamiento ya permite la comunicación con la DB-Tier completa, así que mientras la VM de BD permanezca en dicho Tier, el comportamiento seguirá siendo permitido.

Esto me facilita también la gestión, ya que el equipo de desarrollo ya no deberá especificar que contra que direcciones IP se debe comunicar una app en particular, sino que basta con decir “el servicio Python debe comunicarse con el Tier de BD”, lo cual permite simplificar la configuración de los comportamientos.

Maquinas que están en “descubrimiento” están aprendiendo el comportamiento de la VM y sus app.  Estas VM aun no están aplicando ninguna regla ni gestionando la postura de seguridad de la VM.  El equipo de seguridad debe verificar los comportamientos que se han aprendido, y una vez validados dejar la VM en modo “Protected” en el cual las reglas comienzan a ser aplicadas y la VM se encuentra protegida.

 

Podemos activar o desactivar una regla, además de modificar el comportamiento aplicado, además de si será aplicado automáticamente o manualmente (lo cual implica que tendremos que activar la acción manualmente luego de recibir la alerta).

 

Enforce Host Module Integrity se encarga de monitorear que ningún comportamiento anómalo intente manipular la Protective Memory configurada por el hypervisor en la VM.  Si esto ocurre, como vemos en la imagen,  la acción será suspender la VM, pudiendo tambien en otros casos apagar la VM directamente.

Si dentro de la VM ejecutamos un proceso cuyo comportamiento no esté permitido, este será bloqueado.  En este caso, se está intentando comunicarse con una BD no registrada, y no se está utilizando el proceso asociado, es decir no se está utilizando Python para comunicarse a través del puerto 1433, sino simplemente un script de PowerShell.  

Si bien se está utilizando el puerto 1433 el cual se encuentra abierto en el Firewall, el comportamiento es considerado anormal al no estar definido como un comportamiento valido en AppDefense, y como tal se aplican las reglas configuradas previamente, lo cual implica bloquear completamente este trafico y generar una notificación.

Al revisar las alertas podemos decidir si mantener el bloqueo de este comportamiento o marcar la opción “Allow Behavior” permitiendo dicho comportamiento.   Aqui podemos ver que efectivamente se ha ejecutado un script de PowerShell intentando comunicarse con el puerto 1434 de un servidor de base de datos, no obstante no está permitido este comportamiento por lo cual es bloqueado por las reglas configuradas en AppDefense.

 

Si un atacante intenta generar conexiones maliciosas, estas entonces serán consideradas como comportamiento “anormal” y podrán ser notificadas y/o bloqueadas por AppDefense.  Del mismo modo, el atacante podria intentar desactivar el control de seguridad, momento en el cual podria intentar modificar la zona de memoria protegida o Protective Memory.  Según como mencionamos previamente, en cualquier momento que alguien intente manipular esta zona protegida, se enviará una notificación inmediatamente ademas de opcionalmente generar alguna acción.  Basta con que se modifique un bit en la Protective Memory para que se activen las notificaciones y/o acciones.

Las acciones pueden ser configuradas para activarse automaticamente, o como vemos en la imagen anterior, que solo se reciba una notificación, y que el administrador decida si aplicar o no la acción de manera manual, en este casos “suspender” la VM.  Simplemente presionamos la acción destacada en la barra superior, y luego la confirmamos en la ventana emergente que se desplegará en la interfaz.


Conclusion

Como podemos ver, AppDefense es una excelente solución de seguridad para el datacenter, cambiando además el paradigma en la forma en protegemos las VM y App dentro de un SDDC.

AppDefense no requiere de NSX para correr, NSX es un componente opcional que podemos usar para apalancar acciones de remediación a través de tags y Security Policies.  Sin NSX, AppDefense aun puede generar diversas acciones de remediación que impidan la propagación y exfiltración.

Un requerimiento obligatorio, es que la plataforma vSphere se encuentre al menos en versión 6.5.

Espero les haya resultado interesante esta nueva solucion de VMware.  Una vez que VMware vaya liberando más detalles respecto a AppDefense, podremos ir publicando nueva información en este blog.  Saludos!

About the Author:

EnglishPortugueseSpanish