Monitoreo de seguridad en la nube

La transferencia de datos y aplicaciones a las nubes es un nuevo problema para los SOC corporativos que no siempre están listos para monitorear la infraestructura de otras personas. Según Netoskope, una empresa mediana (aparentemente todavía en los EE. UU.) Utiliza 1246 servicios en la nube diferentes, que es un 22% más que hace un año. 1246 servicios en la nube !!! 175 de ellos están relacionados con los servicios de recursos humanos, 170 están relacionados con el marketing, 110 en el campo de las comunicaciones y 76 en finanzas y CRM. Cisco utiliza "total" 700 servicios externos en la nube. Por lo tanto, estoy un poco confundido por estos números. Pero, en cualquier caso, el problema no está en ellos, sino en el hecho de que las nubes están siendo utilizadas activamente por un número creciente de empresas que desean tener las mismas capacidades para monitorear la infraestructura de la nube que en su propia red. Y esta tendencia está creciendo: según la Oficina de Auditoría Estadounidense , para 2023, 1.200 centros de datos cerrarán en los Estados Unidos (6.250 ya han cerrado). Pero la transición a la nube no es solo "sino que transfiramos nuestros servidores a un proveedor externo". Nueva arquitectura de TI, nuevo software, nuevos procesos, nuevas restricciones ... Todo esto hace cambios significativos en el trabajo no solo de TI, sino también de seguridad de la información. Y si los proveedores aprendieron a lidiar con la seguridad de la nube en sí (el beneficio de las recomendaciones es bastante), entonces hay dificultades significativas con el monitoreo de la seguridad de la información en la nube, especialmente en las plataformas SaaS, de las que hablaremos.



Digamos que su empresa ha trasladado parte de su infraestructura a la nube ... Detente. No asi. Si la infraestructura se transfiere, y solo ahora está pensando en cómo la monitoreará, entonces ya habrá perdido. Si esto no es Amazon, Google o Microsoft (y con reservas), entonces probablemente no tendrá muchas oportunidades para monitorear sus datos y aplicaciones. Bueno, si tienes la oportunidad de trabajar con registros. A veces, los datos sobre eventos de seguridad estarán disponibles, pero no tendrá acceso a ellos. Por ejemplo, Office 365. Si tiene la licencia E1 más barata, los eventos de seguridad no están disponibles para usted. Si tiene una licencia E3, sus datos se almacenan en solo 90 días, y solo si tiene E5: la duración de los registros está disponible durante un año (aunque hay algunos matices asociados con la necesidad de solicitar por separado una serie de funciones de registro del soporte de Microsoft). Por cierto, la licencia E3 es mucho más débil en términos de funciones de monitoreo que el intercambio corporativo. Para alcanzar el mismo nivel, necesita una licencia E5 o una licencia de cumplimiento avanzado adicional, que puede requerir dinero adicional que no se incluyó en su modelo financiero para la transición a la infraestructura de la nube. Y este es solo un ejemplo de una subestimación de los problemas relacionados con el monitoreo de la nube IS. En este artículo, sin pretender estar completo, quiero llamar la atención sobre algunos matices que deben tenerse en cuenta al elegir un proveedor de la nube desde el punto de vista de la seguridad. Y al final del artículo, se proporcionará una lista de verificación, que debe completarse antes de considerar que se ha resuelto el problema de la supervisión de la seguridad de la información en la nube.

Hay varios problemas típicos que conducen a incidentes en entornos de nube, a los que los servicios de IB no tienen tiempo para responder o no ven nada:

• Los registros de seguridad no existen. Esta es una situación bastante común, especialmente para los principiantes en el mercado de la nube. Pero ponerles fin de inmediato no vale la pena. Los jugadores pequeños, especialmente los domésticos, son más sensibles a los requisitos de los clientes y pueden implementar rápidamente algunas funciones solicitadas cambiando la hoja de ruta aprobada a sus productos. Sí, no será un análogo de GuardDuty de Amazon o el módulo Proactive Defense de Bitrix, sino al menos algo.
• IB no sabe dónde se almacenan los registros o no hay acceso a ellos. Aquí es necesario entablar negociaciones con el proveedor de servicios en la nube; tal vez él proporcionará dicha información si considera que el cliente es importante para sí mismo. Pero en general, esto no es muy bueno cuando el acceso a los registros se proporciona "por una decisión especial".
• También sucede que el proveedor de la nube tiene registros, pero proporcionan monitoreo y registro de eventos limitados, insuficientes para detectar todos los incidentes. Por ejemplo, solo se le pueden dar los registros de cambios en el sitio o los registros de intentos de autenticar a los usuarios, pero no pueden proporcionar otros eventos, por ejemplo, sobre el tráfico de red, que le ocultará una capa completa de eventos que caracterizan los intentos de entrar en su infraestructura de nube.
• Hay registros, pero el acceso a ellos es difícil de automatizar, lo que los hace monitorear no continuamente, sino de acuerdo con un cronograma. Y si aún no puede descargar los registros en modo automático, cargar registros, por ejemplo, en formato Excel (como con algunos proveedores de soluciones de nube domésticas), puede conducir a la falta de voluntad para meterse con ellos desde el servicio de IS corporativo.
• Sin registro de monitoreo. Esta es quizás la razón más incomprensible para la ocurrencia de incidentes de seguridad de la información en entornos de nube. Parece que hay registros y puede automatizar el acceso a ellos, pero nadie lo hace. Por qué

Concepto de seguridad compartida en la nube

Pasar a las nubes es siempre la búsqueda de un equilibrio entre el deseo de mantener el control sobre la infraestructura y transferirla a las manos más profesionales del proveedor de la nube, que se especializa en mantenerla. Y en el campo de la seguridad en la nube, este equilibrio también debe buscarse. Además, dependiendo del modelo utilizado para proporcionar servicios en la nube (IaaS, PaaS, SaaS), este equilibrio siempre será diferente. En cualquier situación, debemos recordar que hoy todos los proveedores de la nube siguen el llamado modelo de responsabilidad compartida y seguridad de la información compartida. La nube es responsable de algo, el cliente es responsable de algo, después de haber colocado sus datos, sus aplicaciones, sus máquinas virtuales y otros recursos en la nube. Sería una tontería esperar que tras haber entrado en la nube, transferiremos toda la responsabilidad al proveedor. Pero construir toda la seguridad por su cuenta cuando se muda a la nube tampoco es razonable. Se necesita un equilibrio, que dependerá de muchos factores: - estrategias de gestión de riesgos, modelos de amenazas disponibles para el proveedor de la nube de mecanismos de defensa, legislación, etc.



Por ejemplo, la clasificación de los datos alojados en la nube es siempre responsabilidad del cliente. Un proveedor de la nube o un proveedor de servicios externo solo puede ayudarlo con un conjunto de herramientas que lo ayudará a marcar datos en la nube, identificar violaciones, eliminar datos que violen la ley o enmascararlos utilizando un método u otro. Por otro lado, la seguridad física es siempre responsabilidad del proveedor de la nube, que no puede compartir con los clientes. Pero todo lo que hay entre los datos y la infraestructura física es precisamente el tema de discusión en este artículo. Por ejemplo, la disponibilidad en la nube es responsabilidad del proveedor, y establecer las reglas de la UIT o habilitar el cifrado es responsabilidad del cliente. En este artículo, trataremos de ver qué tipo de mecanismos de seguridad de la información son proporcionados por varios proveedores de nube populares hoy en Rusia, cuáles son las características de su aplicación y cuándo mirar en la dirección de soluciones de superposición externa (por ejemplo, Cisco E-mail Security) que expanden las capacidades de su nube en parte ciberseguridad En algunos casos, especialmente al seguir una estrategia de múltiples nubes, no tendrá más remedio que usar soluciones de monitoreo de seguridad externas en varios entornos de nube a la vez (por ejemplo, Cisco CloudLock o Cisco Stealthwatch Cloud). Bueno, en algunos casos, comprenderá que el proveedor de la nube que ha elegido (o que le ha impuesto) no ofrece ninguna opción para monitorear la seguridad de la información. Esto es desagradable, pero también mucho, ya que le permite evaluar adecuadamente el nivel de riesgo asociado con el trabajo con esta nube.

Ciclo de vida de monitoreo de seguridad en la nube

Para monitorear la seguridad de las nubes que usa, solo tiene tres opciones:

• confíe en las herramientas proporcionadas por su proveedor de la nube,
• aproveche las soluciones de terceros que supervisarán las plataformas IaaS, PaaS o SaaS que utiliza,
• Cree su propia infraestructura de monitoreo en la nube (solo plataformas IaaS / PaaS).

Veamos qué características tiene cada una de estas opciones. Pero primero, debemos comprender el esquema general que se utilizará en el monitoreo de plataformas en la nube. Destacaría 6 componentes principales del proceso de monitoreo de seguridad de la información en la nube:

• Preparación de infraestructura. Identificación de las aplicaciones y la infraestructura necesarias para recopilar eventos que son importantes para la seguridad de la información en el repositorio.
• Colección En esta etapa, los eventos de seguridad se agregan desde varias fuentes para su posterior transmisión al procesamiento, almacenamiento y análisis.
• Procesamiento En este punto, los datos se transforman y enriquecen para facilitar su posterior análisis.
• Almacenamiento. Este componente es responsable del almacenamiento a corto y largo plazo de los datos procesados ​​y sin procesar recopilados.
• Análisis En esta etapa, tiene la capacidad de detectar incidentes y responder a ellos de forma automática o manual.
• Informes Esta etapa ayuda a generar indicadores clave para las partes interesadas (gerencia, auditores, proveedores de la nube, clientes, etc.) que nos ayudan a tomar ciertas decisiones, por ejemplo, cambiar el proveedor o fortalecer el SI.

Comprender estos componentes le permitirá determinar rápidamente qué puede obtener de su proveedor y qué tendrá que hacer usted mismo o con la ayuda de consultores externos.

Servicios en la nube incorporados

Ya escribí anteriormente que tantos servicios en la nube hoy en día no ofrecen ninguna posibilidad de monitorear la seguridad de la información. En general, no prestan mucha atención al tema de la seguridad de la información. Por ejemplo, uno de los servicios rusos populares para enviar informes a agencias gubernamentales a través de Internet (no mencionaré específicamente su nombre). Toda la sección de seguridad de este servicio gira en torno al uso de herramientas de protección de información criptográfica certificadas. La sección de seguridad de la información de otro servicio doméstico en la nube para la gestión de documentos electrónicos ya no es un ejemplo. Habla de certificados de clave pública, criptografía certificada, eliminación de vulnerabilidades web, protección contra ataques DDoS, aplicación de la UIT, copia de seguridad e incluso realizar auditorías regulares de IS. Pero ni una palabra sobre monitoreo, ni sobre la posibilidad de obtener acceso a eventos de seguridad de la información que puedan ser de interés para los clientes de este proveedor de servicios.

En general, por la forma en que el proveedor de la nube describe los problemas de seguridad de la información en su sitio web y en la documentación, uno puede entender cuán en serio generalmente toma este problema. Por ejemplo, si lee los manuales de los productos My Office, no hay una palabra sobre seguridad y la documentación para el producto separado My Office. KS3 ", diseñado para proteger contra el acceso no autorizado, es la enumeración habitual de las cláusulas de la orden 17 del FSTEC, que ejecuta" My office.KS3 ", pero no se describe cómo se implementa y, lo más importante, cómo integrar estos mecanismos con la seguridad de la información corporativa. Tal vez esa documentación esté allí, pero no la encontré en el dominio público en el sitio de My Office. ¿Aunque tal vez simplemente no tengo acceso a esta información clasificada? ..



La misma situación de Bitrix es mucho mejor. La documentación describe los formatos de los registros de eventos y, curiosamente, el registro de intrusiones, que contiene eventos relacionados con posibles amenazas a la plataforma en la nube. Desde allí puede obtener IP, nombre de usuario o nombre de invitado, origen del evento, hora, Agente de usuario, tipo de evento, etc. Es cierto que puede trabajar con estos eventos desde el panel de control de la nube o cargar datos en formato MS Excel. Ahora es difícil automatizar el trabajo con los registros de Bitrix y tendrá que hacer parte del trabajo manualmente (cargue el informe y cárguelo en su SIEM). Pero si recuerdas eso hasta hace relativamente poco tiempo, y esto no fue posible, entonces este es un gran progreso. Al mismo tiempo, quiero señalar que muchos proveedores de nube extranjeros ofrecen una funcionalidad similar "para principiantes": mire los registros con los ojos a través del panel de control o cargue los datos usted mismo (aunque la mayoría carga datos en formato .csv, no Excel).



Si no considera la opción sin registros, los proveedores de la nube generalmente le ofrecen tres opciones para monitorear eventos de seguridad: paneles, cargar datos y acceder a ellos a través de API. El primero parece resolver muchos problemas para usted, pero esto no es del todo cierto: si hay varias revistas, debe cambiar entre las pantallas que las muestran y perder el panorama general. Además, es poco probable que el proveedor de la nube le brinde la oportunidad de correlacionar los eventos de seguridad y, en general, analizarlos desde el punto de vista de la seguridad (por lo general, se trata de datos sin procesar que necesita comprender). Hay excepciones y hablaremos más sobre ellas. Finalmente, vale la pena preguntar, ¿qué eventos registra su proveedor de la nube, en qué formato y cuánto corresponden a su proceso de monitoreo de IS? Por ejemplo, la identificación y autenticación de usuarios e invitados. El mismo Bitrix le permite registrar la fecha y hora de este evento, el nombre del usuario o invitado (en presencia del módulo Web Analytics), un objeto al que se realiza el acceso y otros elementos típicos de un sitio web. Pero los servicios de IS corporativos pueden necesitar información sobre si un usuario ha iniciado sesión en la nube desde un dispositivo confiable (por ejemplo, en una red corporativa, Cisco ISE implementa esta tarea). ¿Y una tarea tan simple como la función de geo-IP, que ayudará a determinar si la cuenta de usuario del servicio en la nube es robada? E incluso si el proveedor de la nube se lo proporciona, entonces esto no es suficiente. El mismo Cisco CloudLock no solo analiza la geolocalización, sino que utiliza el aprendizaje automático para esto y analiza los datos históricos de cada usuario y rastrea diversas anomalías en los intentos de identificación y autenticación. Solo MS Azure tiene una funcionalidad similar (si hay una suscripción correspondiente).



Hay una dificultad más: dado que para muchos proveedores de la nube, la supervisión de IS es un tema nuevo con el que están empezando a tratar, están cambiando constantemente algo en sus decisiones. Hoy tienen una versión de la API, mañana otra, el tercer día después de mañana. También hay que estar preparado para esto. Lo mismo con la funcionalidad que puede cambiar, que debe tenerse en cuenta en su sistema de monitoreo de seguridad de la información. Por ejemplo, Amazon inicialmente tenía servicios separados de monitoreo de eventos en la nube: AWS CloudTrail y AWS CloudWatch. Luego vino un servicio de monitoreo de eventos IS separado: AWS GuardDuty. Después de un tiempo, Amazon lanzó el nuevo sistema de administración de Amazon Security Hub, que incluye un análisis de los datos recibidos de GuardDuty, Amazon Inspector, Amazon Macie y varios otros. Otro ejemplo es la herramienta de integración de registro de Azure con SIEM - AzLog. Muchos proveedores de SIEM la usaron activamente, hasta que en 2018 Microsoft anunció la finalización de su desarrollo y soporte, lo que puso a muchos clientes que usaron esta herramienta antes del problema (como se resolvió, hablaremos más adelante).

Por lo tanto, supervise cuidadosamente todas las funciones de supervisión que le ofrece su proveedor de la nube. O confíe en proveedores externos de soluciones que actuarán como intermediarios entre su SOC y la nube que desea monitorear. Sí, será más costoso (aunque no siempre), pero luego transferirá toda la responsabilidad a los hombros de los demás. ¿O no todos? ... Recuerde el concepto de seguridad compartida y comprenda que no podemos cambiar nada: tendrá que descubrir cómo los diferentes proveedores de la nube proporcionan monitoreo de seguridad de la información de sus datos, aplicaciones, máquinas virtuales y otros recursos ubicados en la nube. Y comenzaremos con lo que Amazon ofrece en esta parte.

Ejemplo: monitoreo de seguridad en IaaS basado en AWS

Sí, sí, entiendo que Amazon no es el mejor ejemplo en vista del hecho de que es un servicio estadounidense y puede bloquearse como parte de la lucha contra el extremismo y la difusión de información prohibida en Rusia. Pero en esta publicación, me gustaría mostrar cómo las diferentes plataformas en la nube difieren en las capacidades de seguridad de la información y a qué debe prestar atención al transferir sus procesos clave a las nubes desde un punto de vista de seguridad. Bueno, si algunos de los desarrolladores rusos de soluciones en la nube obtienen algo útil para ellos, entonces será genial.



Primero debo decir que Amazon no es una fortaleza inexpugnable. Varios incidentes suceden regularmente a sus clientes. Por ejemplo, los nombres, direcciones, fechas de nacimiento y teléfonos de 198 millones de votantes fueron robados de Deep Root Analytics. 14 millones de registros de suscripción de Verizon robados de Nice Systems, Israel Al mismo tiempo, las capacidades integradas de AWS le permiten detectar una amplia gama de incidentes. Por ejemplo:

• Influencia en la infraestructura (DDoS)
• compromiso de nodo (inyección de comando)
• compromiso de cuenta y acceso no autorizado
• configuración incorrecta y vulnerabilidades
• Interfaces y API desprotegidas.

Esta discrepancia se debe al hecho de que el cliente mismo es responsable de la seguridad de los datos del cliente, como descubrimos anteriormente. Y si no le preocupaba la inclusión de mecanismos de protección y no incluía herramientas de monitoreo, entonces aprenderá sobre el incidente solo de los medios o de sus clientes.

Para detectar incidentes, puede utilizar una amplia gama de diversos servicios de monitoreo desarrollados por Amazon (aunque a menudo se complementan con herramientas externas, como osquery). Por lo tanto, en AWS, se realiza un seguimiento de todas las acciones del usuario, independientemente de cómo se lleven a cabo, a través de la consola de administración, la línea de comandos, el SDK u otros servicios de AWS. Todos los registros de las acciones de cada cuenta de AWS (incluido el nombre de usuario, la acción, el servicio, los parámetros de actividad y su resultado) y el uso de la API están disponibles a través de AWS CloudTrail. Puede ver estos eventos (por ejemplo, iniciar sesión en la consola de AWS IAM) desde la consola de CloudTrail, analizarlos con Amazon Athena o "darlos" a soluciones externas, como Splunk, AlienVault, etc. Los registros de AWS CloudTrail se colocan en su bucket de AWS S3.



Los otros dos servicios de AWS proporcionan algunas capacidades de monitoreo más importantes. En primer lugar, Amazon CloudWatch es un servicio de monitoreo de recursos y aplicaciones de AWS que, entre otras cosas, puede detectar diversas anomalías en su nube. Todos los servicios integrados de AWS, como Amazon Elastic Compute Cloud (servidores), Amazon Relational Database Service (bases de datos), Amazon Elastic MapReduce (análisis de datos) y otros 30 servicios de Amazon, utilizan Amazon CloudWatch para almacenar sus registros. Los desarrolladores pueden usar la API abierta de Amazon CloudWatch para agregar la funcionalidad de monitoreo de registros a las aplicaciones y servicios del usuario, lo que permite expandir el rango de eventos analizados en el contexto de la seguridad de la información.



En segundo lugar, el servicio VPC Flow Logs le permite analizar el tráfico de red enviado o recibido por sus servidores AWS (externa o internamente), así como entre microservicios. Cuando alguno de sus recursos de VPC de AWS interactúa con la red, el servicio de registros de flujo de VPC registra la información de tráfico de la red, incluidas las interfaces de red de origen y destino, así como las direcciones IP, puertos, protocolo, número de bytes y número de paquetes que vio. Aquellos con experiencia en seguridad de redes locales reconocen esto como un análogo de las transmisiones de NetFlow .que pueden crearse mediante conmutadores, enrutadores y firewalls de nivel empresarial. Estos registros son importantes para la supervisión de la seguridad de la información porque, a diferencia de los eventos de actividad de usuarios y aplicaciones, también le permiten no perderse la comunicación de red en el entorno de nube privada virtual de AWS.



Por lo tanto, estos tres servicios de AWS (AWS CloudTrail, Amazon CloudWatch y VPC Flow Logs) en conjunto brindan una visión bastante efectiva del uso de su cuenta, el comportamiento del usuario, la administración de la infraestructura, la actividad de las aplicaciones y servicios, y la actividad de la red. Por ejemplo, se pueden usar para detectar las siguientes anomalías:

• Intenta escanear el sitio, buscar puertas traseras, buscar vulnerabilidades a través de ráfagas de "errores 404"
• Injection- (, SQL injection) “ 500”.
• sqlmap, nikto, w3af, nmap .. User Agent.

Amazon Web Services también ha desarrollado otros servicios de ciberseguridad que abordan muchos otros desafíos. Por ejemplo, AWS tiene un servicio incorporado para auditar políticas y configuraciones: AWS Config. Este servicio proporciona una auditoría continua de sus recursos de AWS y sus configuraciones. Considere un ejemplo simple: suponga que desea asegurarse de que las contraseñas de los usuarios estén deshabilitadas en todos sus servidores y que el acceso solo sea posible sobre la base de certificados. AWS Config facilita la verificación de esto para todos sus servidores. Existen otras políticas que pueden aplicarse a sus servidores en la nube: "Ningún servidor puede usar el puerto 22", "Solo los administradores pueden cambiar las reglas del firewall" o "Solo el usuario Ivashko puede crear nuevas cuentas de usuario, y él puede hacerlo es solo los martes ".En el verano de 2016, AWS Config se expandió para automatizar la detección de violaciones de políticas desarrolladas. Las Reglas de configuración de AWS son, en esencia, solicitudes de configuración continua para los servicios de Amazon que utiliza, que generan eventos en caso de violación de las políticas relevantes. Por ejemplo, en lugar de ejecutar periódicamente solicitudes de configuración de AWS para verificar que todas las unidades del servidor virtual estén encriptadas, las Reglas de configuración de AWS se pueden usar para verificar constantemente las unidades del servidor para esta condición. Y, lo más importante, en el contexto de esta publicación, cualquier violación genera eventos que su servicio de IS pueda analizar.Solicitudes de configuración continua para los servicios de Amazon que usa que generan eventos cuando se violan las políticas. Por ejemplo, en lugar de ejecutar periódicamente solicitudes de configuración de AWS para verificar que todas las unidades del servidor virtual estén encriptadas, las Reglas de configuración de AWS se pueden usar para verificar constantemente las unidades del servidor para esta condición. Y, lo más importante, en el contexto de esta publicación, cualquier violación genera eventos que su servicio de IS pueda analizar.Solicitudes de configuración continua para los servicios de Amazon que usa que generan eventos cuando se violan las políticas. Por ejemplo, en lugar de ejecutar periódicamente solicitudes de configuración de AWS para verificar que todas las unidades del servidor virtual estén encriptadas, las Reglas de configuración de AWS se pueden usar para verificar constantemente las unidades del servidor para esta condición. Y, lo más importante, en el contexto de esta publicación, cualquier violación genera eventos que su servicio de IS pueda analizar.Las Reglas de configuración de AWS se pueden usar para verificar constantemente los discos del servidor para esta condición. Y, lo más importante, en el contexto de esta publicación, cualquier violación genera eventos que su servicio de IS pueda analizar.Las Reglas de configuración de AWS se pueden usar para verificar constantemente los discos del servidor para esta condición. Y, lo más importante, en el contexto de esta publicación, cualquier violación genera eventos que su servicio de IS pueda analizar.



AWS también tiene sus equivalentes a las soluciones tradicionales de seguridad de la información corporativa que también generan eventos de seguridad que puede y debe analizar:

• Detección de intrusos - AWS GuardDuty
• control de fugas - AWS Macie
• EDR (aunque hablar de puntos finales en la nube es un poco extraño) - AWS Cloudwatch + osquery de código abierto o soluciones GRR
• Análisis de flujo de red: AWS Cloudwatch + AWS VPC Flow
• Análisis de DNS: AWS Cloudwatch + AWS Route53
• AD - Servicio de directorio de AWS
• Gestión de cuentas - AWS IAM
• SSO - SSO de AWS
• análisis de seguridad - AWS Inspector
• gestión de la configuración - AWS Config
• WAF - AWS WAF.

No detallaré todos los servicios de Amazon que pueden ser útiles en el contexto de la seguridad de la información. Lo principal que hay que entender es que todos pueden generar eventos que podemos y debemos analizar en el contexto de la seguridad de la información, involucrando tanto las capacidades integradas de Amazon como las soluciones externas, por ejemplo, SIEM, que puede llevar eventos de seguridad a su centro de monitoreo y analizarlos allí junto con eventos de otros servicios en la nube o de infraestructura interna, perímetro o dispositivos móviles.



En cualquier caso, todo comienza con fuentes de datos que le proporcionan eventos del IB. Dichas fuentes incluyen, pero no se limitan a:

• CloudTrail: uso de API y acciones del usuario
• Asesor de confianza - Verificación de seguridad para las mejores prácticas
• Config —
• VPC Flow Logs —
• IAM —
• ELB Access Logs —
• Inspector —
• S3 —
• CloudWatch —
• SNS — .

Amazon, que ofrece una variedad de fuentes de eventos y herramientas para su generación, tiene una capacidad muy limitada para analizar los datos recopilados en el contexto de la seguridad de la información. Deberá estudiar de forma independiente los registros disponibles, buscando los indicadores de compromiso correspondientes en ellos. El AWS Security Hub, que Amazon lanzó recientemente, tiene como objetivo resolver este problema convirtiéndose en una especie de SIEM basado en la nube para AWS. Pero si bien es solo al comienzo de su viaje y está limitado tanto por la cantidad de fuentes con las que trabaja como por otras restricciones establecidas por la arquitectura y las suscripciones de Amazon.

Ejemplo: monitoreo de IS en IaaS basado en Azure

No quiero entrar en un largo debate sobre cuál de los tres proveedores de la nube (Amazon, Microsoft o Google) es mejor (especialmente porque cada uno de ellos tiene sus propias características específicas y es adecuado para resolver sus problemas); enfóquese en las capacidades de monitoreo de seguridad que brindan estos jugadores. Es cierto que Amazon AWS fue uno de los primeros en este segmento y, por lo tanto, ha avanzado más en términos de sus funciones de seguridad de la información (aunque muchos admiten que usarlos es difícil). Pero esto no significa que ignoremos las oportunidades que Microsoft nos ofrece con Google.

Los productos de Microsoft siempre se han distinguido por su "apertura" y en Azure la situación es similar. Por ejemplo, si AWS y GCP siempre provienen del concepto de "todo lo que no está permitido está prohibido", entonces Azure tiene el enfoque exactamente opuesto. Por ejemplo, al crear una red virtual en la nube y una máquina virtual en ella, todos los puertos y protocolos están abiertos y habilitados de manera predeterminada. Por lo tanto, tendrá que dedicar un poco más de esfuerzo a la configuración inicial del sistema de control de acceso en la nube de Microsoft. Y esto también le impone requisitos más estrictos en términos de monitoreo de la actividad en la nube de Azure.



AWS tiene una peculiaridad relacionada con el hecho de que cuando monitorea sus recursos virtuales, si están en diferentes regiones, entonces tiene dificultades para combinar todos los eventos y su análisis único, para eliminar los que necesita recurrir a varios trucos, como Cree un código personalizado para AWS Lambda que transportará eventos entre regiones. No existe tal problema en Azure: su mecanismo de registro de actividad supervisa toda la actividad en toda la organización sin restricciones. Lo mismo ocurre con AWS Security Hub, que recientemente fue desarrollado por Amazon para consolidar muchas funciones de seguridad dentro de un solo centro de seguridad, pero solo dentro de su región, que, sin embargo, no es relevante para Rusia. Azure tiene su propio Centro de seguridad, que no está sujeto a restricciones regionales,proporcionando acceso a todas las funciones de seguridad de la plataforma en la nube. Además, para varios equipos locales, puede proporcionar su propio conjunto de capacidades defensivas, incluidos los eventos de seguridad gestionados por ellos. AWS Security Hub todavía se esfuerza por convertirse en el Centro de seguridad de Azure. Pero vale la pena agregar una mosca en la pomada: puede exprimir mucho de lo que se describió anteriormente en AWS de Azure, pero esto se hace de manera más conveniente solo para Azure AD, Azure Monitor y Azure Security Center. Todos los demás mecanismos de defensa de Azure, incluido el análisis de eventos de seguridad, aún no se administran de la manera más conveniente. Parte del problema se resuelve mediante la API que impregna todos los servicios de Microsoft Azure, pero esto requerirá esfuerzos adicionales para integrar su nube con su SOC y la disponibilidad de especialistas calificados (de hecho,como con cualquier otro SIEM trabajando con API en la nube). Algunos SIEM, que se discutirán más adelante, ya son compatibles con Azure y pueden automatizar la tarea de monitorearlo, pero hay algunas dificultades con él, no todos pueden tomar todos los registros que Azure tiene.



La recopilación y supervisión de eventos en Azure se proporciona mediante el servicio Azure Monitor, que es la herramienta principal para recopilar, almacenar y analizar datos en la nube de Microsoft y sus recursos: repositorios Git, contenedores, máquinas virtuales, aplicaciones, etc. Todos los datos recopilados por Azure Monitor se dividen en dos categorías: métricas en tiempo real que describen indicadores clave de rendimiento de la nube de Azure y registros de registro que contienen datos organizados en registros que caracterizan ciertos aspectos de las actividades de los recursos y servicios de Azure. Además, con la API del recopilador de datos, el servicio Azure Monitor puede recopilar datos de cualquier fuente REST para crear sus propios escenarios de supervisión.



Estas son algunas fuentes de eventos de seguridad que Azure le ofrece a las que puede acceder a través de Azure Portal, CLI, PowerShell o REST API (y algunas solo a través de Azure Monitor / Insight API):

• Registros de actividad: este diario responde a las preguntas clásicas "quién", "qué" y "cuándo" con respecto a cualquier operación de escritura (PUT, POST, DELETE) sobre los recursos de la nube. Los eventos relacionados con el acceso de lectura (GET) no se incluyen en este registro, ni en muchos otros.
• Registros de diagnóstico: contiene datos sobre operaciones con un recurso particular incluido en su suscripción.
• Informes de Azure AD: contiene tanto la actividad del usuario como la actividad del sistema relacionadas con la administración de grupos y usuarios.
• Registro de eventos de Windows y Syslog de Linux: contiene eventos de máquinas virtuales alojadas en la nube.
• Metrics — “” . . 30 .
• Network Security Group Flow Logs — , Network Watcher .
• Storage Logs — , .

Para la supervisión, puede usar SIEM externo o el Monitor de Azure incorporado y sus extensiones. Hablaremos más sobre los sistemas de administración de eventos IS, pero por ahora veremos lo que Azure nos ofrece para analizar datos en el contexto de seguridad. La pantalla principal para todo lo relacionado con la seguridad en Azure Monitor es Log Analytics Security and Audit Dashboard (la versión gratuita admite el almacenamiento de una cantidad limitada de eventos durante solo una semana). Este panel está dividido en 5 áreas principales que visualizan estadísticas resumidas sobre lo que sucede en su entorno de nube:

• Dominios de seguridad: indicadores cuantitativos clave relacionados con la seguridad de la información: la cantidad de incidentes, la cantidad de nodos comprometidos, nodos no parcheados, eventos de seguridad de red, etc.
• Problemas notables: muestra el número y la importancia de los problemas activos de IB
• Detections — ,
• Threat Intelligence — ,
• Common security queries — , .

Las extensiones de Azure Monitor incluyen Azure Key Vault (protección de claves criptográficas en la nube), Evaluación de malware (análisis de protección contra código malicioso en máquinas virtuales), Azure Application Gateway Analytics (análisis de, entre otras cosas, registros de firewall de nube), etc. . Estas herramientas, enriquecidas con ciertas reglas de procesamiento de eventos, le permiten visualizar varios aspectos de la actividad de los servicios en la nube, incluida la seguridad, e identificar ciertas desviaciones del trabajo. Pero, como suele suceder, cualquier funcionalidad adicional requiere una suscripción paga adecuada, lo que requerirá que realice las inversiones financieras adecuadas que necesita planificar con anticipación.



Azure tiene una serie de capacidades integradas de monitoreo de amenazas que están integradas en Azure AD, Azure Monitor y Azure Security Center. Entre ellos, por ejemplo, detectar la interacción de máquinas virtuales con IP maliciosas conocidas (debido a la integración con los servicios de inteligencia de amenazas de Microsoft), detectar malware en la infraestructura de la nube al recibir alarmas de máquinas virtuales ubicadas en la nube, ataques como "adivinar contraseñas" "Para máquinas virtuales, vulnerabilidades en la configuración del sistema de identificación de usuarios, inicio de sesión desde anonimizadores o nodos infectados, pérdida de cuenta, inicio de sesión desde ubicaciones inusuales, etc. Azure hoy es uno de los pocos proveedores de la nube que le ofrece capacidades integradas de Inteligencia de amenazas para enriquecer los eventos de seguridad de la información recopilada.



Como se mencionó anteriormente, la funcionalidad de protección y, como consecuencia, los eventos de seguridad generados por ella no son accesibles para todos los usuarios por igual, pero requiere una cierta suscripción que incluye la funcionalidad que necesita, que genera los eventos correspondientes para monitorear la seguridad de la información. Por ejemplo, algunas de las funciones para monitorear anomalías en las cuentas descritas en el párrafo anterior solo están disponibles en la licencia premium P2 para Azure AD. Sin ella, usted, como en el caso de AWS, tendrá que analizar los eventos de seguridad recopilados "manualmente". Y, también, dependiendo del tipo de licencia para Azure AD, no todos los eventos para análisis estarán disponibles para usted.

En Azure Portal, puede administrar ambas consultas de búsqueda en los registros que le interesan y configurar paneles para visualizar indicadores clave de seguridad de la información. Además, allí puede elegir las extensiones de Azure Monitor, que le permiten ampliar la funcionalidad de los registros de Azure Monitor y obtener un análisis más profundo de los eventos desde el punto de vista de la seguridad.



Si necesita no solo la capacidad de trabajar con registros, sino también el centro de seguridad integral de su plataforma en la nube de Azure, incluida la administración de las políticas de IS, puede hablar sobre la necesidad de trabajar con el Centro de seguridad de Azure, la mayoría de los cuales son útiles por una tarifa, por ejemplo, detección de amenazas, monitoreo fuera de Azure, evaluación de conformidad, etc. (En la versión gratuita, solo tiene acceso a una evaluación de seguridad y recomendaciones para resolver los problemas identificados). Consolida todos los problemas de seguridad en un solo lugar. De hecho, podemos hablar de un mayor nivel de seguridad de la información que proporciona Azure Monitor, ya que en este caso los datos recopilados en su fábrica de la nube se enriquecen con una variedad de fuentes, como Azure, Office 365, Microsoft CRM en línea, Microsoft Dynamics AX, Outlook .com, MSN.com, la Unidad de Delitos Digitales de Microsoft (DCU) y el Centro de Respuesta de Seguridad de Microsoft (MSRC), que se superponen a varios algoritmos sofisticados de aprendizaje automático y análisis de comportamiento, que en última instancia deberían aumentar la eficiencia de la detección y respuesta de amenazas.

Azure tiene su propio SIEM, apareció a principios de 2019. Este es el Azure Sentinel, que se basa en datos de Azure Monitor, y también puede integrarse con él. soluciones de seguridad externas (por ejemplo, NGFW o WAF), cuya lista se actualiza constantemente. Además, a través de la integración de la API de seguridad de Microsoft Graph, puede conectar sus propias fuentes de Inteligencia de amenazas a Sentinel, lo que enriquece la capacidad de analizar incidentes en su nube de Azure. Se puede argumentar que Azure Sentinel es el primer SIEM "nativo" que apareció en los proveedores de la nube (el mismo Splunk o ELK, que se puede colocar en la nube, por ejemplo, AWS, todavía no son desarrollados por los proveedores de servicios en la nube tradicionales). Azure Sentinel and Security Center podría llamarse SOC para la nube de Azure, y podrían estar limitados (con ciertas reservas) si ya no tenía infraestructura y si transfirió todos sus recursos informáticos a la nube y sería una nube de Microsoft Azur



Pero dado que las capacidades integradas de Azure (incluso con una suscripción a Sentinel) a menudo no son suficientes para la supervisión de IS y la integración de este proceso con otras fuentes de eventos de seguridad (tanto en la nube como internos), existe la necesidad de exportar los datos recopilados a sistemas externos, que puede incluir SIEM. Esto se hace con la ayuda de la API y con la ayuda de extensiones especiales que están disponibles oficialmente en este momento solo para los siguientes SIEM: Splunk (complemento de Azure Monitor para Splunk), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight y ELK. Más recientemente, hubo más SIEM, pero a partir del 1 de junio de 2019, Microsoft dejó de admitir la herramienta Azure Log Integration Tool (AzLog), que en los albores de Azure y en ausencia de la normalización normal de trabajar con registros (Azure Monitor ni siquiera existía) lo hizo fácil Integre SIEM externos con Microsoft Cloud. Ahora la situación ha cambiado y Microsoft recomienda la plataforma Azure Event Hub como la principal herramienta de integración para el resto de SIEM. Muchos ya han implementado esta integración, pero tenga cuidado: es posible que no capturen todos los registros de Azure, sino solo algunos (consulte la documentación de su SIEM).

Concluyendo una breve excursión a Azure, quiero dar una recomendación general sobre este servicio en la nube: antes de decir nada sobre las funciones de monitoreo de seguridad en Azure, debe configurarlas con mucho cuidado y probar que funcionan como está escrito en la documentación y como le dijeron los consultores. Microsoft (y pueden tener diferentes puntos de vista sobre el rendimiento de las características de Azure). Si tiene las capacidades financieras de Azure, puede obtener mucha información útil sobre el monitoreo de seguridad de la información. Si sus recursos son limitados, como en el caso de AWS, tendrá que confiar solo en sus propias fortalezas y datos sin procesar que Azure Monitor le proporciona. Y recuerde que muchas funciones de monitoreo cuestan dinero y es mejor familiarizarse con los precios por adelantado. Por ejemplo, puede almacenar datos durante 31 días por un máximo de 5 GB para un cliente de forma gratuita; exceder estos valores requerirá que desembolse adicionalmente (aproximadamente $ 2+ por almacenar cada GB adicional del cliente y $ 0.1 por almacenar 1 GB cada mes adicional) ) Trabajar con telemetría y métricas de aplicaciones también puede requerir recursos financieros adicionales, así como trabajar con alertas y notificaciones (un cierto límite está disponible de forma gratuita, lo que puede no ser suficiente para sus necesidades).

Ejemplo: monitoreo de IS en IaaS basado en Google Cloud Platform

Google Cloud Platform en el contexto de AWS y Azure parece bastante joven, pero esto es en parte bueno. A diferencia de AWS, que estaba desarrollando sus capacidades, incluidas las defensivas, gradualmente, teniendo problemas con la centralización; GCP, como Azure, se gestiona mucho mejor de forma centralizada, lo que reduce la cantidad de errores y el tiempo de implementación en la empresa. Desde un punto de vista de seguridad, GCP se encuentra, curiosamente, entre AWS y Azure. También tiene un registro de evento único para toda la organización, pero está incompleto. Algunas funciones todavía están en modo beta, pero gradualmente esta deficiencia debería eliminarse y GCP se convertirá en una plataforma más madura en términos de monitoreo de seguridad de la información.



La herramienta principal para grabar eventos en GCP es Stackdriver Logging (un análogo de Azure Monitor), que le permite recopilar eventos en toda su infraestructura de nube (así como con AWS). Desde una perspectiva de seguridad en GCP, cada organización, proyecto o carpeta tiene cuatro registros:

• Actividad de administración: contiene todos los eventos relacionados con el acceso administrativo, por ejemplo, creación de una máquina virtual, cambio de derechos de acceso, etc. Este diario siempre se escribe, independientemente de su deseo, y almacena sus datos durante 400 días.
• Acceso a datos: contiene todos los eventos relacionados con el trabajo con datos de usuarios de la nube (crear, modificar, leer, etc.). Por defecto, este diario no está escrito, porque su volumen se hincha muy rápidamente. Por esta razón, su vida útil es de solo 30 días. Además, lejos de todo está escrito en este diario. Por ejemplo, no escribe eventos relacionados con recursos que están disponibles públicamente para todos los usuarios o que son accesibles sin iniciar sesión en GCP.
• Evento del sistema: contiene eventos del sistema que no están relacionados con los usuarios o las acciones de un administrador que cambia la configuración de los recursos de la nube. Siempre se escribe y almacena durante 400 días.
• Access Transparency es un ejemplo único de un libro de registro que registra todas las acciones de los empleados de Google (pero aún no para todos los servicios de GCP) que obtienen acceso a su infraestructura como parte de sus responsabilidades laborales. Este diario se almacena durante 400 días y no está disponible para todos los clientes de GCP, pero solo está sujeto a una serie de condiciones (ya sea soporte Gold o Platinum, o la presencia de 4 roles de cierto tipo como parte del soporte corporativo). Una característica similar también está disponible, por ejemplo, en Office 365 - Lockbox.

Ejemplo de registro: transparencia de acceso

{  insertId:  "abcdefg12345"  jsonPayload: {  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"  location: {   principalOfficeCountry:  "US"   principalEmployingEntity:  "Google LLC"   principalPhysicalLocationCountry:  "CA"  }  product: [   0:  "Cloud Storage"  ]  reason: [   detail:  "Case number: bar123"   type:  "CUSTOMER_INITIATED_SUPPORT"  ]  accesses: [   0: {   methodName: "GoogleInternal.Read"   resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"   }  ]  }  logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"  operation: {  id:  "12345xyz"  }  receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"  resource: {  labels: {   project_id:  "1234567890"  }  type:  "project"  }  severity:  "NOTICE"  timestamp:  "2017-12-18T16:06:24.660001Z" } 

El acceso a estos registros es posible de varias maneras (de la misma manera que antes lo consideraban Azure y AWS): a través de la interfaz Log Viewer, a través de la API, a través del SDK de Google Cloud o a través de la página Actividad de su proyecto, en el que está interesado en eventos. Del mismo modo, también se pueden exportar a soluciones externas para análisis adicionales. Esto último se realiza exportando registros a BigQuery o al almacenamiento Cloud Pub / Sub.

Además de Stackdriver Logging, la plataforma GCP también ofrece la funcionalidad de Monitoreo de Stackdriver, que le permite rastrear métricas clave (rendimiento, MTBF, estado general, etc.) de servicios y aplicaciones en la nube. Los datos procesados ​​y visualizados pueden facilitar la búsqueda de problemas en su infraestructura en la nube, incluso en el contexto de seguridad. Pero debe tenerse en cuenta que esta funcionalidad no será muy rica precisamente en el contexto de la seguridad de la información, ya que hoy GCP no tiene un análogo del mismo AWS GuardDuty y no puede distinguir los malos de todos los eventos grabados (Google desarrolló Event Threat Detection, pero hasta ahora es en beta y hablamos de su utilidad temprano). Stackdriver Monitoring podría usarse como un sistema para detectar anomalías, que luego se investigarán para encontrar las causas de su aparición. Pero en las condiciones de escasez de personal calificado en el campo de la seguridad de la información GCP en el mercado, esta tarea en este momento parece difícil.



También vale la pena enumerar algunos de los módulos de seguridad de la información que se pueden usar dentro de su nube GCP y que son similares a lo que ofrece AWS:

• Cloud Security Command Center es un análogo de AWS Security Hub y Azure Security Center.
• Cloud DLP: detección y edición automáticas (por ejemplo, enmascaramiento) de datos ubicados en la nube, de acuerdo con más de 90 políticas de clasificación predefinidas.
• Cloud Scanner es un escáner de vulnerabilidades conocidas (XSS, inyección de flash, bibliotecas no parcheadas, etc.) en App Engine, Compute Engine y Google Kubernetes.
• Cloud IAM: control de acceso a todos los recursos de GCP.
• Identidad en la nube: administre cuentas de usuario, dispositivos y aplicaciones de GCP desde una única consola.
• Cloud HSM: protección de clave criptográfica.
• Servicio de gestión de claves en la nube: gestión de claves criptográficas en GCP.
• Control de servicio de VPC: cree un perímetro seguro alrededor de sus recursos GCP para protegerlos de fugas.
• Titan Security Key: protección contra el phishing.

Muchos de estos módulos generan eventos de seguridad que se pueden enviar a BigQuery para su análisis o exportación a otros sistemas, incluido SIEM. Como ya se mencionó anteriormente, GCP es una plataforma desarrollada activamente y ahora Google está desarrollando una serie de nuevos módulos de seguridad de la información para su plataforma. Entre ellos se encuentran la detección de amenazas de eventos (ahora disponible en versión beta), que escanea los registros de Stackdriver en busca de rastros de actividad no autorizada (similar a GuardDuty en AWS), o Inteligencia de políticas (disponible en alfa), que permitirá desarrollar políticas de acceso inteligente a los recursos de GCP.

Hice una breve revisión de las capacidades de monitoreo integradas en plataformas populares en la nube. Pero, ¿tiene especialistas que puedan trabajar con los registros sin procesar del proveedor de IaaS (no todos están listos para comprar funciones avanzadas de AWS o Azure o Google)? Además, muchos conocen el proverbio "confiar, pero verificar", que en el campo de la seguridad es tan cierto como siempre. ¿Cuánto confía en las capacidades integradas del proveedor de la nube que le envía eventos IB? ¿Cuánto se centran en la seguridad de la información?

A veces vale la pena buscar soluciones de superposición para monitorear las infraestructuras de la nube que pueden complementar la seguridad de la nube incorporada, y a veces tales soluciones son la única forma de obtener datos sobre la seguridad de sus datos y aplicaciones ubicadas en la nube. Además, son simplemente más convenientes, ya que se encargan de todas las tareas de analizar los registros necesarios generados por diferentes servicios en la nube de diferentes proveedores de la nube. Un ejemplo de una solución tan impuesta es Cisco Stealthwatch Cloud, que se centra en la única tarea: monitorear las anomalías de IS en entornos de nube, incluidos no solo Amazon AWS, Microsoft Azure y Google Cloud Platform, sino también nubes privadas.

Ejemplo: monitoreo de seguridad con Stealthwatch Cloud

AWS proporciona una plataforma informática flexible, pero esta flexibilidad facilita a las empresas cometer errores que conducen a problemas de seguridad. Y el modelo IS compartido solo contribuye a esto. Ejecutar software en la nube con vulnerabilidades desconocidas (por ejemplo, AWS Inspector o GCP Cloud Scanner puede luchar contra vulnerabilidades conocidas), contraseñas débiles, configuraciones incorrectas, información privilegiada, etc. Y todo esto afecta el comportamiento de los recursos en la nube, que Cisco Stealthwatch Cloud puede observar, que es un sistema para monitorear la seguridad de la información y la detección de ataques. nubes públicas y privadas.



Una de las características clave de Cisco Stealthwatch Cloud es la capacidad de modelar entidades. Con él, puede crear un modelo de software (es decir, simular casi en tiempo real) de cada uno de sus recursos en la nube (no importa si es AWS, Azure, GCP u otra cosa). Estos pueden incluir servidores y usuarios, así como tipos de recursos específicos para su entorno de nube, como grupos de seguridad y grupos de escala automática. Estos modelos utilizan flujos de datos estructurados proporcionados por los servicios en la nube como entrada. Por ejemplo, para AWS, estos serán VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda y AWS IAM. El modelado de entidades detecta automáticamente el rol y el comportamiento de cualquiera de sus recursos (puede hablar sobre el perfil de toda la actividad en la nube). Dichos roles incluyen un dispositivo móvil Android o Apple, un servidor Citrix PVS, un servidor RDP, una pasarela de correo, un cliente VoIP, un servidor terminal, un controlador de dominio, etc. Luego monitorea continuamente su comportamiento para determinar cuándo ocurre un comportamiento arriesgado o que amenaza la seguridad. Puede identificar el descifrado de contraseñas, ataques DDoS, fugas de datos, acceso remoto ilegal, código malicioso, escaneo de vulnerabilidades y otras amenazas. Por ejemplo, esto es lo que parece detectar un intento de acceso remoto desde un país atípico de su organización (Corea del Sur) al clúster de Kubernetes a través de SSH:



Y así es como se ve la supuesta filtración de información de la base de datos de Postgress en un país con el que no se ha interactuado previamente:



Finalmente, así es como se ven demasiados intentos fallidos de acceso SSH desde China e Indonesia desde un dispositivo remoto externo:



O suponga que una instancia de servidor en una VPC, de acuerdo con la política, nunca debería ser un destino para el inicio de sesión remoto. Además, suponga que se ha producido un inicio de sesión remoto en esta computadora debido a un cambio erróneo en la política de reglas del firewall. La función de modelado de entidades detectará e informará esta actividad ("Acceso remoto inusual") casi en tiempo real y señalará una llamada específica de AWS CloudTrail, Azure Monitor o GCP Stackdriver Logging API (incluyendo nombre de usuario, fecha y hora, entre otros detalles), que causó el cambio a la regla de ITU. Y luego esta información se puede dar a SIEM para su análisis.



Características similares están disponibles para cualquier entorno de nube compatible con Cisco Stealthwatch Cloud:



El modelado de entidades es una forma única de automatización de seguridad que puede detectar un problema previamente desconocido con su gente, procesos o tecnologías. Por ejemplo, le permite detectar, entre otras cosas, problemas de seguridad como:

• ¿Alguien encontró una puerta trasera en el software que usamos?
• ¿Hay algún software o dispositivo de terceros en nuestra nube?
• ¿Un usuario autorizado abusa de los privilegios?
• ¿Hubo un error de configuración que permitió el acceso remoto u otro uso inadvertido de los recursos?
• ¿Hay alguna fuga de datos de nuestros servidores?
• ¿Alguien intentó conectarse con nosotros desde una ubicación geográfica atípica?
• ¿Nuestra nube está infectada con código malicioso?

El evento IB detectado puede transmitirse en forma de un boleto correspondiente a Slack, Cisco Spark, el sistema de gestión de incidentes PagerDuty, y también puede enviarse a varios SIEM, incluidos Splunk o ELK. Resumiendo, podemos decir que si su empresa utiliza una estrategia de múltiples nubes y no se limita a un solo proveedor de la nube, las capacidades de monitoreo de seguridad de la información descritas anteriormente, luego usar Cisco Stealthwatch Cloud es una buena opción para obtener un conjunto unificado de capacidades de monitoreo para los principales jugadores de la nube: Amazon , Microsoft y Google. Lo más interesante es que si compara los precios de Stealthwatch Cloud con las licencias avanzadas de monitoreo de seguridad en AWS, Azure o GCP, puede resultar que la solución de Cisco sea aún más barata que las capacidades integradas de las soluciones de Amazon, Microsoft y Google. Paradójicamente, lo es. Y cuantas más nubes y sus capacidades use, más obvia será la ventaja de una solución consolidada.



Además, Stealthwatch Cloud también puede monitorear nubes privadas implementadas en su organización, por ejemplo, en base a contenedores de Kubernetes o monitoreando flujos de Netflow o tráfico de red recibido a través de la duplicación en equipos de red (incluso producción nacional), datos de AD o servidores DNS etc. Todos estos datos se enriquecerán con información de Inteligencia de amenazas recopilada por Cisco Talos, el grupo no gubernamental más grande del mundo de investigadores de amenazas de SI.



Esto le permite implementar un sistema de monitoreo unificado para nubes públicas e híbridas que su empresa puede usar. La información recopilada puede analizarse utilizando las funciones integradas de Stealthwatch Cloud o enviarse a su SIEM (Splunk, ELK, SumoLogic y varios otros son compatibles de forma predeterminada).

Esto concluye la primera parte del artículo en el que examiné las herramientas integradas y externas para monitorear plataformas IaaS / PaaS que nos permiten detectar y responder rápidamente a incidentes en los entornos de nube que nuestra empresa ha elegido. En la segunda parte, continuaremos con el tema y consideraremos las opciones de monitoreo para las plataformas SaaS usando Salesforce y Dropbox como ejemplo, y también trataremos de resumir y unir todo, creando un sistema unificado de monitoreo de seguridad de la información para diferentes proveedores de la nube.