Geekly articles weekly

Monitoreo de seguridad en la nube. Parte 2

Por lo tanto, continuaré el artículo sobre el monitoreo de la seguridad de los proveedores de la nube. En la primera parte, hablé sobre la experiencia de Cisco al trabajar con servicios externos en la nube, así como las observaciones de Cisco que encontramos al construir o auditar los SOC de nuestros clientes. Tomando en la primera parte, como ejemplo, las tres soluciones más populares de Amazon, Microsoft y Google, que son plataformas IaaS / PaaS, hoy es hora de hablar sobre el monitoreo de las plataformas SaaS: Dropbox, Salesforce.com, Slack y Apple Business Manager, y también sobre qué SIEM son más adecuados para monitorear plataformas en la nube hoy en día.

Ejemplo: monitoreo de IS en SaaS basado en Dropbox


Si sobre la base de AWS, Azure o GCP puede crear un análogo casi completo de su infraestructura corporativa, solo en la nube, es decir, servicios en la nube que realizan una tarea específica, por ejemplo, el almacenamiento de archivos, como lo hace Dropbox. Este servicio ha ido mucho más allá del almacenamiento de usuario habitual, proporcionando a sus usuarios corporativos un conjunto completo de mecanismos de seguridad:

  • identificación de usuario y autenticación
  • control de acceso a archivos
  • eliminación remota de datos
  • gestión de dispositivos de confianza
  • integración con soluciones externas de seguridad de la información (DLP, SSO, DRM, eDiscovery, SIEM, etc.)
  • registro de eventos de seguridad.

imagen

Los registros de Dropbox Business (que no es posible en la versión Básica o Pro) registran los siguientes tipos de eventos de seguridad:

  • configuración de protección con contraseña
  • intentos exitosos y no exitosos de ingresar al almacenamiento de archivos
  • controlar el acceso privilegiado y las acciones del administrador
  • acciones de archivo (agregar, editar, eliminar, transferir, cargar, etc.)
  • conexión al almacenamiento de archivos de aplicaciones de terceros
  • dispositivos que acceden a Dropbox
  • agregar / eliminar miembros para acceder a grupos
  • crear carpetas / archivos accesibles externamente

imagen

Puede analizar eventos de seguridad en Dropbox ya sea a través de la consola administrativa de Dropbox Business (pero no espere grandes revelaciones) o utilizando la solución de monitoreo externo que opera con la API de Dropbox Business. El acceso a los registros no está disponible en ninguna tarifa comercial de Dropbox, pero solo comienza con una licencia avanzada (recuerde Office365, que tampoco inicia el acceso a los registros con una licencia comercial básica). Al igual que con AWS, ¿vale la pena preguntar si su SIEM es compatible con Dropbox? Por ejemplo, Splunk tiene un módulo separado para trabajar con Dropbox que, gracias a la API REST, le permite monitorear los siguientes eventos de seguridad:

  • iniciar sesión
  • actividad al agregar / eliminar / solicitudes de usuario
  • actividad de dispositivos que se conectan a Dropbox
  • actividad de intercambio de archivos dentro y fuera de la empresa
  • actividad de aplicación
  • etc.

Otros SIEM no tienen soporte integrado de Dropbox; tendrá que escribir su propio conector.

Ejemplo, monitoreo de IS en SaaS basado en Slack y Salesforce.com


Entendemos que hoy en día existe una gran cantidad de plataformas en la nube que las empresas pueden usar para resolver sus problemas y que nos gustaría monitorear desde el punto de vista de su seguridad. No nos sumergiremos en cada una de estas plataformas (y no establecí tal tarea, solo queriendo prestar atención a los detalles de las tareas de monitoreo de la seguridad de la información de la plataforma en la nube), pero trataremos de completar la discusión con el ejemplo de plataformas específicas con dos soluciones comerciales más comunes: Slack y Salesforce.com .

Slack se integra con más de 50 herramientas de seguridad (desde protección de contenido y privacidad hasta monitoreo de certificados y control de acceso), pero desde el punto de vista de monitorear una amplia gama de eventos de seguridad, Slack tiene pocas integraciones listas: en el sitio, esta lista se limita al poco conocido Symantec CloudSOC, Cisco CloudLock (más sobre eso a continuación) y Chronicle. Eso es probablemente todo. Pero con la certificación de ISO 27001, SOC2 / 3, Fed-RAMP y otros, Slack no pudo evitar implementar la funcionalidad avanzada para monitorear su infraestructura, algunas de las cuales están disponibles para los clientes. En particular, utilizando la API de registros de auditoría (disponible solo para usuarios de Slack Enterprise Grid y no disponible en planes Free, Standard, Plus), puede "extraer" una amplia gama de datos de su infraestructura de Slack y cargarlos en su SIEM relacionados con la actividad del usuario, pero no con monitoreo de contenido (para estas tareas es necesario usar soluciones DLP o eDiscovery especializadas). Al mismo tiempo, Slack no tiene un mecanismo similar a AWS GuardDuty: envía eventos "tal cual" y no le dice si son malos o buenos, solo usted puede determinarlo escribiendo sus propias reglas de correlación en su SIEM o utilizando soluciones externas que tengan un conjunto de patrones predefinidos de actividad no autorizada en Slack (como, por ejemplo, en Cisco CloudLock).

Cada evento en el libro de registro de Slack tiene 4 elementos clave: una acción, el usuario que lo generó (actor), la entidad asociada con el evento (espacio de trabajo, aplicación, usuario, canal, archivo) y ubicación (contexto) dentro de la cual ocurrió esta acción (un espacio de trabajo separado o toda la organización). En total, Slack captura alrededor de 70 acciones diferentes. Por ejemplo, así es como se ve un evento de registro de usuario en Slack:

{ "entries":[ { "id":"0123a45b-6c7d-8900-e12f-3456789gh0i1", "date_create":1521214343, "action":"user_login", "actor":{ "type":"user", "user":{ "id":"W123AB456", "name":"Charlie Parker", "email":"bird@slack.com" } }, "entity":{ "type":"user", "user":{ "id":"W123AB456", "name":"Charlie Parker", "email":"bird@slack.com" } }, "context":{ "location":{ "type":"enterprise", "id":"E1701NCCA", "name":"Birdland", "domain":"birdland" }, "ua":"Mozilla\/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/64.0.3282.186 Safari\/537.36", "ip_address":"1.23.45.678" } } ] }

Con Salesforce, la situación es similar: con la API, puede acceder a toda la actividad del usuario en este CRM en la nube y, en particular, a los siguientes eventos:

  • iniciar sesión
  • cerrar sesión
  • informe de carga
  • Llamadas a la API
  • URI (clics web en Salesforce Classic)
  • Lightning (clics web en la aplicación móvil Lightning Experience y Salesforce)
  • Descargas de páginas de Visualforce
  • Ejecución de Apex
  • Y otros

Además, puede supervisar la seguridad de su instancia de Salesforce y trabajar con registros de eventos en la consola de administración de Salesforce. Tienes 4 opciones:

  • Supervisión de todos los intentos de acceso al portal SFDC. La página Historial de inicio de sesión muestra 20,000 entradas sobre cómo ingresar al portal en los últimos 6 meses (indicando el método de inicio de sesión HTTP: GET, POST u otros). Si necesita una historia más larga, el registro correspondiente se puede descargar en formato .csv o .gzip.
  • Seguimiento del trabajo de campo en CRM. A través de la consola de administración, puede realizar un seguimiento del historial de trabajo con campos CRM en la nube estándar y personalizados durante los últimos 18 meses, y a través de la API obtenga acceso a un historial de dos años de cambios de campo. También puede archivar esta historia por hasta 10 años y, si es necesario, acceder a ella.
  • Seguimiento de cambios administrativos. Usando la función Setup Audit Trail, puede monitorear más de 100 acciones de todos sus administradores (especialmente si hay varias) durante los últimos 180 días.
  • Monitoreo de transacciones Con el servicio Transaction Security, puede capturar eventos de Salesforce en tiempo real y aplicarles notificaciones y alarmas con la lógica de procesamiento adecuada.

imagen

Recientemente, Salesforce ha desarrollado una solución de monitoreo de seguridad especializada para su plataforma: Salesforce Shield. Incluye tres componentes: administrar el cifrado de toda la información almacenada, monitorear la seguridad y el uso de datos, y administrar las políticas de seguridad. En el caso de la supervisión de la seguridad de la información, esta función en Salesforce Shield es similar a las extensiones de Azure Monitor, que no solo muestran eventos, sino que también debido a su procesamiento y visualización le indican qué buscar. Por ejemplo, ¿puede averiguar desde qué dispositivos y plataformas los usuarios acceden con mayor frecuencia a SFDC? ¿O cuándo, con mayor frecuencia, y desde dónde los usuarios ingresan su copia de Salesforce (esto puede ayudar a identificar puntos de entrada atípicos)? ¿Quién ve la información confidencial? ¿Quién suele descargar informes a su computadora? Las respuestas a estas preguntas se pueden obtener utilizando 16 paneles preinstalados, cuya entrada es analizada por el subsistema Einstein Event Monitoring Analytics con licencia por separado (buen nombre, ¿no?). Con su ayuda, también puede modelar sus paneles, cargar datos en sistemas de BI externos, etc.

Ejemplo: monitoreo de seguridad de la información en iPhone y iPad


Vaya ... ¿Y de dónde viene el iPhone y el monitoreo en la nube? Todo es simple aquí. Por ejemplo, ninguno de los SIEM al momento de escribir este artículo tenía un conector para la plataforma Apple Business Manager (o el Apple School Manager, que es más conocido en las universidades de EE. UU.), Que le permite administrar dispositivos corporativos de Apple: iPhone, iPad, Mac. Para esta tarea, puede usar cualquiera de las soluciones de MDM, o puede usar el Apple Business Manager (si participa en el Programa de inscripción de dispositivos de Apple o el Programa de compras por volumen, que no son válidos en Rusia). Las soluciones MDM se pueden instalar localmente e integrarlas con su SIEM es básicamente fácil, al igual que los MDM en la nube (por ejemplo, Cisco Meraki), pero la historia con Apple Business Manager tiene un color de nube pronunciado y en el contexto de este artículo es interesante Vea cómo uno de los mayores fabricantes de TI resuelve el problema de proporcionar la capacidad de monitorear la seguridad de sus soluciones.

En general, es desde este punto de vista que las decisiones de Apple en Rusia no son muy conocidas (aunque en Occidente nos enfrentamos a ellas en proyectos SOC). De ahí la opinión predominante de que Apple es una empresa puramente de consumo que no ha recurrido a los clientes corporativos en términos de integración en sus SOC. Esto no es así al mismo tiempo. El hecho es que, al tener un sistema de protección suficientemente potente para iOS y MacOS, Apple continúa siendo una empresa conjunta cerrada y no permite de manera muy activa a terceros la información sobre la seguridad de sus productos. Aunque la imagen está cambiando gradualmente. Por ejemplo, Apple Business Manager le permite ver información sobre la actividad en los dispositivos corporativos de Apple, que se combina en tres bloques de información: el evento, el estado y la fecha de inicio del evento (con la fecha de finalización, por desgracia, problemas). Los eventos controlados (el Apple School Manager tiene un poco más, pero están relacionados con estudiantes / estudiantes) incluyen:

  • Enviar nuevos registros por correo electrónico
  • Crear nuevos inicios de sesión
  • Enviar nuevos códigos de verificación por correo electrónico
  • Asignar roles
  • Eliminar cuentas
  • Desactivar cuentas
  • Cuentas reactivas
  • Asignar dispositivos
  • Desasignar dispositivos
  • Dispositivos de liberación
  • Anular asignación y eliminar servidor
  • Reasignar y eliminar servidor.

Para ser sincero, no hay mucha información. Puede trabajar con él en el panel de control de Apple Business Manager o cargándolo como un archivo .csv en su computadora para su posterior análisis. Debo admitir que la orientación principal de esta función en Apple todavía se centra en encontrar problemas en el plano de TI, en lugar de abordar problemas de seguridad: Apple no tiene ninguna recopilación o análisis de registros automatizados. Puede obtener mucha más información si integra Apple Business Manager con cualquier solución de MDM; luego puede obtener información sobre usuarios activos, ID de usuario y dispositivos, incluida la dirección Wi-Fi, datos sobre aplicaciones instaladas y sus versiones, presencia de actualizaciones desinstaladas, operador de telecomunicaciones, punto de acceso personal, función habilitada "Buscar iPhone", cifrado de datos, jailbreak, certificados instalados, disponibilidad y configuración de una ITU personal, configuración de PIN cuando, control remoto fenómenos, etc. Esto es suficiente para las tareas de monitoreo de IS, pero requerirá ciertos gestos para integrar sus dispositivos Apple corporativos en su SOC.

SIEM para monitoreo en la nube


Cabe señalar que Amazon, como muchas otras nubes públicas, prestando mucha atención a su seguridad, se centra principalmente en los mecanismos para detectar y prevenir amenazas bastante simples en su infraestructura, así como para proporcionar acceso a eventos que pueden analizarse utilizando decisiones externas Microsoft estuvo más cerca de crear un sistema para monitorear y analizar eventos de seguridad en la nube, pero usar su solución requerirá inversiones financieras adicionales. Si usa solo las nubes de esta empresa, quizás pueda limitarse a Azure Security Center con extensiones. Pero si tiene un entorno de múltiples nubes, entonces vale la pena considerar el uso de soluciones independientes: SIEM, que, tal vez, ya esté utilizando para monitorear la seguridad de la información de su infraestructura interna. Y aquí debe comprender cómo seleccionó o eligió SIEM admite la nube que usa (y sus diversos servicios) como fuente de datos. Por ejemplo, Splunk, QRadar, ArcSight, ELK admiten AWS y esto se indica directamente en la documentación de estos sistemas de monitoreo, pero el mismo RuSIEM o PT SIEM no es compatible.

Debe tenerse en cuenta que diferentes SIEM pueden tomar datos de diferentes servicios en la nube de diferentes maneras. Tomemos por ejemplo ELK y Amazon. Muchos servicios y aplicaciones en la nube pueden reenviar sus eventos al bucket de S3, y Logstash puede recogerlos a pedido. AWS CloudWatch mencionado anteriormente también puede enviar datos a S3, y puede transmitirlos a AWS Lambda (y Logstash los toma para su análisis) o alojarlos en la nube ElasticSearch. Bueno, por supuesto, hay aplicaciones que pueden enviar datos directamente a ELK, sin pasar por S3, Lambda o CloudWatch. IBM QRadar recopila los datos del mismo AWS GuardDuty a través de AWS CloudWatch, los registros de registros de flujo de VPC de Amazon al publicarlos en la cesta S3 seguidos de capturas en QRadar, y los datos de AWS CloudTrail a través de la cesta S3 o a través de AWS CloudWatch. Dependiendo de los datos que necesite para monitorear, este conocimiento puede ayudarlo a no cometer un error fatal al elegir SIEM, que después de la implementación no podrá trabajar con las aplicaciones y servicios en la nube que necesita.

A pesar de la popularidad de AWS o Azure, varios SIEM no tienen conectores integrados para trabajar con nubes de Amazon y Microsoft, pero es posible crear uno propio, ya sea de forma independiente o con la ayuda del fabricante, como, por ejemplo, en el caso de PT SIEM con conector personalizado. Vale la pena señalar que AWS no es el ejemplo correcto para tener una idea de cómo funciona SIEM con las nubes. AWS es la plataforma de negocios en la nube más popular del mundo y, por lo tanto, muchos fabricantes, incluidos aquellos en el campo de la tecnología de la información, están tratando de integrar sus productos con ella. Pero incluso en este caso, debemos admitir que, en general, SIEM hoy en día no le permite monitorear plataformas en la nube. Por ejemplo, IBM QRadar solo funciona con los siguientes servicios en la nube (sin incluir los servicios en la nube IB como Cisco Umbrella, Cisco Meraki, Cisco Threat Grid, etc.):

  • AWS GuardDuty y AWS CloudTrail (otros servicios de AWS aún no compatibles)
  • Caja
  • Cloudera
  • Sra. Azul
  • Salesforce

La lista no es muy larga. La misma base de módulos Splunk para trabajar con nubes es mucho más amplia. Además de lo mencionado anteriormente para IBM Qradar, la solución de Splunk también admite:

  • Office365
  • ServiceNow
  • Kinesis amazónica
  • Holgura
  • Jira
  • Google drive
  • Nube de Google
  • Nagios
  • Aplicación G Suite
  • Docker
  • Kubernetes
  • y otros

Tenga en cuenta que nadie admite GCP todavía.

Usando la aplicación Splunk para la extensión AWS (la idea será similar para ArcSight o QRadar), puede implementar, por ejemplo, los siguientes escenarios de monitoreo de casos de uso que le permitirán responder preguntas importantes desde el punto de vista de la seguridad de la información:

  • ¿Quién agregó la regla al grupo de seguridad que protege nuestros servidores de aplicaciones?
  • ¿De dónde viene el tráfico bloqueado a VPC?
  • ¿Cuál fue la actividad de un usuario en particular antes y después del incidente?
  • Notificarme cuando un grupo de seguridad permita el acceso desde todos los puertos
  • ¿Qué grupos de seguridad están definidos pero no están asociados con ningún recurso?
  • Notificarme cuando se accederá a la consola desde una dirección IP externa
  • Notificarme cuando se comete un agente de usuario típico de ataques web
  • ¿Cuándo se exceden los recursos de la instancia en X%?

Algunos SIEM diseñados específicamente para la red corporativa pueden tener problemas arquitectónicos con las nubes. Como mínimo, deberá abrir una serie de reglas para todos sus sistemas en la nube que envíen registros a su SIEM en el perímetro ITU. Otro problema, y ​​más grave, es el hecho de que tener conectores para trabajar con las nubes no significa que SIEM esté listo para usar en este rol. Si prestamos atención a los componentes del sistema de monitoreo mencionados al comienzo de 6, resulta que el conector a SIEM lo ayuda a resolver dos tareas necesarias, pero claramente insuficientes: recopilar y procesar eventos de seguridad de la información. El almacenamiento es proporcionado por el propio SIEM, pero con el análisis aún tenemos una gran pregunta. Si un SIEM corporativo típico tiene una proporción de reglas de correlación “listas para usar” realmente útiles y funcionales con respecto al número total de reglas es de 20 a 80, entonces, para monitorear la seguridad de la información en la nube, esta proporción será de alrededor de 5 a 95, o incluso menos. Por lo tanto, no olvide que la presencia de SIEM trabajando con nubes no es todo lo que se necesita para monitorear su seguridad real. Necesitará mucho más esfuerzo (sin mencionar personal calificado) para escribir reglas de correlación de eventos para su nube, para sus nubes, así como para las nubes y el entorno corporativo (porque probablemente querrá correlacionar los datos de ubicación del usuario conectado a la plataforma en la nube con características de seguridad corporativas).

Si la situación con el monitoreo de IaaS / PaaS es más o menos buena: la cantidad de fuentes, el volumen de registros creados y los tipos de eventos son suficientes para su análisis, entonces, para muchos SaaS, esto todavía causa dificultades. Por lo tanto, quiero prestar atención a las siguientes actividades / eventos que están disponibles para los jugadores SaaS más serios y que deben analizarse en su SIEM al monitorear SaaS:

  • Acceso de usuario y administrador
    • Intentos de inicio de sesión exitosos y fallidos
    • Hora y lugar de entrada.
    • Tipo de dispositivo de entrada y atributos
    • Intentos de inicio de sesión fallidos seguidos de un éxito
    • Actividad de SSO
    • Actividad de AD
  • Comportamiento del usuario
    • Actividad del archivo de usuario (descarga, eliminación, copia, impresión, transferencia, envío)
    • "Compartir" archivos con usuarios externos e internos
    • Crear enlaces abiertos / compartidos
    • Actividad desde dispositivos móviles no autorizados / no confiables
    • Actividad de red
  • Acceso a API de terceros
    • Cambios de privilegios de API
    • Actividad relacionada con el certificado OAuth
    • Actividad asociada con el token OAuth.

Como mínimo, un análisis de estos eventos, que, por ejemplo, Salesforce.com, Box o Dropbox le proporcionará, le permitirá identificar una gran cantidad de incidentes con sus datos y usuarios de la nube.

¿Cómo explicar tal brecha en la capacidad de monitorear entornos corporativos y en la nube con SIEM? Baja prevalencia de nubes? Entendemos que esto no es así. Más bien, la pregunta es la madurez de los clientes que ya están listos para las nubes, pero que no están listos para monitorear su seguridad, como escribí al comienzo del artículo. Y sin esto, no se recluta el número requerido de casos de negocios y los desarrolladores de SIEM no tienen prisa por iniciativa propia para implementar el soporte en la nube en sus productos; especialmente en el contexto de cambios regulares en los mecanismos de trabajo y la devolución de eventos de seguridad de los proveedores de la nube (recordemos la historia de AzLog con Azure).

Qué hacer cuando su proveedor no tiene herramientas de monitoreo


Pero, ¿qué sucede si su proveedor de la nube tiene registros, pero no tiene sus propias herramientas para analizarlos y monitorearlos, su SIEM no es compatible con su nube elegida y no hay forma de escribirle un conector? Existe una opción que le permite utilizar intermediarios especializados que, utilizando la API de nube existente (debería serlo), acceden a su proveedor de nube y luego extraen registros de él, les aplican varias herramientas analíticas, identificando varios incidentes y otras irregularidades, cuyos datos entonces puede ser entregado a su SIEM.

Ejemplos de tales intermediarios son Cloud Access Security Broker, soluciones CASB (por ejemplo, Cisco CloudLock), o algunas soluciones MFA de autenticación multifactor con capacidades avanzadas de control de acceso (por ejemplo, Cisco Duo). Es cierto, CASB o MFA, al resolver un problema, agregar otro, obtener otra consola de administración, que debe integrarse en su SOC. Pero resolver este problema suele ser más simple. SIEM, a menudo sin un conector en la nube, puede trabajar con herramientas de seguridad de la información, incluidos CASB y MFA (después de todo, esta es su tarea principal). En este caso, las API de CASB y MFA ayudan, lo que le permite enviar eventos de seguridad recopilados y analizados a SIEM corporativos e incrustarlos en sus SOC. Resulta un sistema de tres niveles en el que SIEM, que no tiene que integrarse directamente con la nube, utiliza CASB / MFA para esto (en el caso anterior con Cisco Stealthwatch Cloud, la misma historia).

imagen

Es cierto que CASB tampoco es una panacea. No todos los proveedores de la nube tienen API en sus plataformas que permiten enviar datos a SOC y SIEM corporativos. Por lo general, es este atributo el que distingue las decisiones corporativas. A veces, incluso las soluciones en la nube populares no tienen tales API, como se podía ver al principio, cuando mencioné las soluciones Bitrix, "My Office" o SKB Kontur.

Ejemplo: monitoreo de seguridad con Cisco CloudLock


Cisco CloudLock es una solución basada en API que se integra con una amplia gama de populares plataformas SaaS en la nube, como G Suite, Salesforce, Office 365, Dropbox, Box, ServiceNow, Slack, Okta, etc., así como con IaaS / PaaS plataformas como Salesforce y AWS. A diferencia del proxy CASB, la solución basada en API le permite trabajar con datos que ya están cargados en la nube, analizar el tráfico entre nubes y controlar el acceso desde dispositivos personales y corporativos móviles y no administrados. Al mismo tiempo, Cisco CloudLock, que gradualmente se está convirtiendo en una parte integral de Cisco Umbrella , no interfiere con el trabajo del usuario y se conecta a nubes controladas debido a su API, lo que le permite monitorear violaciones como:

  • adivinar la contraseña
  • iniciar sesión desde una ubicación atípica (robo de cuenta)

    imagen
  • violación de las reglas para trabajar con información confidencial (almacenamiento en la nube de información que no debería estar allí)

    imagen
  • malware en la nube
  • fuga de datos

    imagen
  • violación de los requisitos reglamentarios
  • Acceso desde aplicaciones prohibidas o caducadas.

    imagen

El acceso a estos incidentes es posible tanto desde el propio servicio Cisco CloudLock como a través de SIEM, a lo que CloudLock proporciona la información necesaria a través de la API existente. Actualmente, Cisco CloudLock puede integrarse con Splunk, QRadar y Arcsight.

imagen

SOC


Entonces, tenemos una idea de cómo funciona el monitoreo de seguridad de la información en entornos de nube populares en Rusia. Ahora comprende qué datos y cómo puede cargarlos en su SIEM. Pero, ¿significa esto que puede hablar sobre un sistema de monitoreo de nube IS integrado? Por supuesto que no. Es suficiente recordar que según el concepto popular, pero no del todo correcto, SOC es una combinación de personas, procesos y tecnologías. Hablamos arriba solo sobre tecnología. Ha llegado el momento de hablar un poco sobre otros componentes.

Para empezar, el mundo de la nube de hoy no tiene un claro favorito y líder. Las empresas usan diferentes nubes para diferentes tareas. Arriba, di un ejemplo de Cisco, que utiliza alrededor de 700 proveedores de nube en todo el mundo en sus actividades.Y todos son diferentes, con diferentes enfoques para garantizar la seguridad de la información y su monitoreo. Con el fin de integrarlos a todos en nuestro centro de monitoreo de SI, es necesario mirar más allá de las formas de cargar datos en SIEM y construir una estrategia completa de monitoreo de múltiples nubes, que necesariamente incluye los siguientes pasos:

  1. , ( use case). use case Splunk. , . , , - “”. , ? use case . — , .

    imagen
  2. playbook' runbook', .
  3. , use case, . , , . Amazon — ( , , ..), ( , , Amazon EC2 VPC) (, , ). , , .
  4. , , , , .
  5. , . , , Threat Intelligence, , , ( Cisco Stealthwatch Cloud), (, Amazon Web Services ), , - . .
  6. , .
  7. , , , - . , - osquery.
  8. , (, WORM — Write Once, Read Many), (, AWS Key Management System) (, Amazon S3 Glacier).
  9. , , Threat Intelligence, (, GCP Azure), . , . , , .
  10. (SIEM), CASB NTA (, Cisco Stealthwatch Cloud).

    imagen
  11. Threat Hunting, , . , , — . .
  12. .

Debe tenerse en cuenta que algunos de estos componentes se superpondrán con otras tareas de monitoreo que su organización pueda enfrentar: monitoreo de SLA, monitoreo de disponibilidad, monitoreo de rendimiento de la aplicación, monitoreo de uso para la facturación posterior, etc. Por lo tanto, cuando construya el sistema de monitoreo de seguridad de la información de su nube, primero especifique lo que ya se ha hecho y lo que planean hacer sus colegas de otros departamentos: puede usar los logros o herramientas ya realizados o compartir varias tareas con otros.

Parece que no escribí nada especial y nuevo. Si su SOC está diseñado correctamente inicialmente, entonces agregar una nueva entidad controlada (ya sea la nube, ICS o dispositivos móviles) no debería conducir a una fuerte alteración de los documentos y procesos desarrollados previamente. Cuando diseñamos o realizamos una auditoría SOC, intentamos inicialmente tener en cuenta todos estos aspectos en nuestro trabajo.

Conclusión


En resumen, vale la pena repetir nuevamente que el monitoreo de la seguridad de la información en entornos de nube es un tema relativamente nuevo incluso para los "viejos" del mercado de la nube. Por lo tanto, se están produciendo cambios constantemente en este segmento, y algo que no era posible hasta hace poco aparece en la cartera del proveedor de la nube. Lo mismo se aplica a las funciones de monitoreo de SI. Independientemente del proveedor del que estemos hablando, pueden brindarle una de varias opciones de monitoreo:
  • — .
  • SIEM . , “” /.
  • API, “” . .
  • .
  • Acceda a través de intermediarios que recopilan los datos de la nube que le interesan, los enriquecen con información adicional y aplican diversas herramientas y algoritmos analíticos, después de lo cual transfieren el resultado del análisis a su SIEM o al sistema de análisis de eventos de seguridad de la información.

Todas estas cinco opciones difieren en la complejidad de trabajar con ellas, el precio y la velocidad del monitoreo y la respuesta. No puedo decir cuál elegir, ya que depende mucho no solo de la nube con la que esté trabajando, sino también de cuál es su estrategia de monitoreo. IB. Solo puedo ayudarlo con una lista de preguntas que debe hacerse usted y su proveedor de la nube, con quien decide “conectar su vida”:

  • ¿Trabaja / planea trabajar con una nube o con varias?
  • ¿Qué mecanismos de protección ofrece su proveedor de nube? Depende de lo que pueda monitorear y lo que no.
  • ISO 27001, Fed-RAMP, SOC2/3? , - - .
  • ? .
  • ? ( )?
  • / ? , , .
  • ? ? ? threat hunting? - Threat Intelligence?
  • ? / ?
  • API ?
  • SIEM ? /API ( )?
  • “” SIEM? use case ?
  • SIEM ? — SIEM?
  • SIEM CASB?
  • SIEM TI- ?

Aquí hay una breve lista de preguntas, cuyas respuestas le permitirán comenzar a construir el proceso de monitoreo de la seguridad de la información de los entornos de nube que usted o su empresa decidieron usar. Cuanto antes se interese en responder estas preguntas, más barato le costará construir un sistema de monitoreo y menos incidentes ocurrirán con sus recursos dados a proveedores externos de la nube. Como lo demuestra la experiencia de Cisco en la construcción o auditoría de los SOC, incluso los centros de monitoreo de SI más exitosos que se ocupan de incidentes dentro de la red corporativa no siempre promueven las capacidades de monitoreo de la nube en su arquitectura, lo que requiere su reestructuración. Espero que las observaciones y recomendaciones descritas en estas dos partes ayuden a garantizar la ciberseguridad.

Source: https://habr.com/ru/post/468395/

More articles:


All Articles