Uso del Elastic Stack como una navaja suiza de operaciones de seguridad basadas en SaaS

En RS2, la seguridad ocupa un lugar esencial en todo lo que hacemos. Nuestro producto principal, BankWORKS, es una solución integrada completa y con todas las características para todas las necesidades de procesamiento de pagos: desde la adquisición de transacciones mediante dispositivos hasta el pago final y la integración con el libro mayor. Grandes y pequeños bancos, procesadores y proveedores de servicios de pagos de todo el mundo, tanto simples como complejos, usan este software. También ofrecemos el producto como servicio administrado y hospedado.

Como equipo, somos responsables de garantizar que se minimice el riesgo de filtración o vulneración de los datos en todos los aspectos de nuestro negocio y de asegurar, al mismo tiempo, el cumplimiento de varios requisitos; debemos realizar todo esto mientras evitamos interrupciones en las operaciones cotidianas.

En noviembre de 2017 planificábamos el crecimiento de nuestro equipo de seguridad. Sin embargo, antes de conseguir la aprobación para más contrataciones, necesitábamos aliviar un poco el esfuerzo manual que implicaba el manejo de incidentes y eventos de seguridad. Este fue el inicio de nuestro viaje con el Elastic Stack.

El viaje desde la propuesta hasta la producción

Etapas iniciales

Después de haber usado el Elastic Stack en otras funciones, y para proyectos personales, quería presentar el producto al equipo. Pensaba que cumpliría todos nuestros requisitos gracias a su amplio conjunto de características y escalabilidad.

En los primeros días en mi nueva función en RS2, activé instancias de Elasticsearch y Kibana (versión 6, en este caso) en una máquina virtual en mi laptop, instalé un par de Beats en la MV en sí (packetbeat, auditbeat, metricbeat y filebeat) y envié todos los datos directamente a Elasticsearch. El proceso completo tardó aproximadamente una hora (de la cual se necesitaron 40 minutos para la descarga e instalación de la imagen ISO del sistema operativo) para que se completen datos significativos en Kibana.

Le mostré esto a mi colega y casi instantáneamente estuvo de acuerdo en que era el camino a seguir y en que debíamos crear una demostración para el equipo ejecutivo usando datos reales para destacar la efectividad. Decidimos incluir algunos dispositivos de red y servidores existentes que no requerirían cambios en nuestra red de producción (usando los distintos Beats y Logstash) y algunas integraciones de terceros.

Evaluación de la cloud

En funciones anteriores, me ocupé de grandes despliegues de Elastic que abarcaban varios servidores. Sin embargo, nunca presté atención realmente a la oferta de Elastic Cloud. Casualmente, RS2 estaba “congelada estructuralmente” debido a la inminente migración a la cloud. Esto, junto con los plazos ajustados y los recursos limitados, me llevó a explorar Elastic Cloud. Como profesional de seguridad, era escéptico. Quería asegurarme de que el servicio estuviera diseñado teniendo en cuenta cierto grado de seguridad.

Una vez que tuve el cluster, realicé algunas pruebas de seguridad rápidas para intentar detectar vulnerabilidades o puntos débiles muy obvios. Esto es lo que descubrí:

• Elastic te permite elegir entre AWS y GCP como proveedor cloud de backend, por lo que se heredan todas sus característica de seguridad, junto con las certificaciones de cumplimiento.
• Se usan redes segregadas para cada cluster, y no las subredes predeterminadas para cada proveedor.
• Se usan cifrados y configuraciones TLS modernos tanto para la URL de Elasticsearch como para la de Kibana.
• Los puertos de transporte de Elasticsearch se asignan de forma aleatoria.
• También se asignan de forma completamente aleatoria las URL de cada instancia, por lo que no es posible enumerar los nombres de clientes.
• No es posible acceder directamente a la IP sin la ID del cluster.
• Se usa la versión más reciente del Elastic Stack, junto con una versión reciente de Java 8.

La combinación de todo

Una vez listo mi cluster de cloud, tuve que diseñar los flujos de datos. En el diagrama a continuación se detalla la arquitectura de la POC.

Como teníamos X-Pack disponible, Watcher se usó mucho como parte del marco de trabajo de alerta. Esto se integró con un Slackbot personalizado usando las acciones de webhook de Watcher.

Preparación de la demostración: El trabajo con los datos

El primer paso consistió en parsear y enriquecer lo más posible los logs. En un contexto de seguridad, el enriquecimiento es clave para resolver incidentes rápidamente, debido a que reduce en gran medida el tiempo de investigación para los analistas. También ayuda a filtrar los falsos positivos. Mediante diversos plugins de filtros de Logstash, pude hacerlo con facilidad. Además, para abastecer nuestra herramienta existente de archivado de logs, pude configurar varias salidas de Logstash para que envíen los datos simultáneamente al cluster de Elastic y a la herramienta existente de archivado.

La lista a continuación incluye algunas de las operaciones de enriquecimiento agregadas a nuestros logs parseados:

• Datos GeoIP (ubicación y ASN)
• Búsquedas de IP de malware
• Búsquedas de usuarios con inicio de sesión permitido
• Parseo de agentes de usuario
• Decodificación de URL

Esta es una lista parcial de los enriquecimientos configurados para la POC. Se agregaron muchos más una vez realizado el paso a producción.

Cuando ya contaba con todos estos datos bien parseados, creé dashboards personalizados para que trabajen junto con los integrados y destaquen algunas de las características de enriquecimiento mencionadas previamente. Estos son solo unos ejemplos de algunos de los dashboards de Kibana personalizados que desarrollamos para la POC (se eliminaron todos los datos confidenciales):

Además, agregué otras ingeniosas integraciones para la demostración con la intención de mostrar lo sencillo que es agregar datos a Elastic. A fin de cuentas, es solo otro índice. Un ejemplo de esto fue una integración con el popular servicio “Have I been Pwned” de Troy Hunt. El servicio proporciona una API REST muy útil que permite buscar si se detecta una dirección de correo electrónico en una vulneración de datos divulgada. Se creó una vigilancia para que nos alerte sobre cualquier entrada nueva sobre nuestro dominio.

Alerta

La idea detrás del marco de trabajo de alerta en la POC (para usar después en producción) era poder accionar todo desde Slack. Los siguientes son algunos ejemplos de los datos manipulados dentro del Slackbot. Se incluye todo lo que un analista necesita para iniciar una investigación. Los datos usados se recopilaron a través diferentes Beats; y los logs de dispositivos de red parseados, a través de Logstash.

Algunos de los sets de datos incluyeron lo siguiente:

• Logs de retransmisión SMTP, logs de autenticación y logs packetfilter de nuestros firewalls
• Solicitudes de DNS a nivel del paquete, mediante Packetbeat
• Logs SSH/SFTP, mediante una combinación de Wazuh y Filebeat
• Una lista de procesos y sus estados, mediante Metricbeat
• Monitoreo de sockets de red saliente, mediante Auditbeat en sistemas *nix

Estos son solo unos ejemplos de algunas de las alertas de Slackbot que desarrollamos para la POC (se eliminaron todos los datos confidenciales):

• Alerta de conexión con TeamViewer
  
  
• Alerta de inicio de sesión del firewall
  
  
• Alerta de malware
  
  

Los resultados

Como es evidente, la POC fue un gran éxito y se aprobó el paso a producción. Quisiera reiterar los puntos principales gracias a los cuales no tuvimos inconvenientes en la POC:

• La facilidad y velocidad excepcionales de uso de Elastic Cloud y todo lo que comprende (backups integrados desde el primer momento, resistencia y alta disponibilidad, paquete con X-Pack para nuestro tamaño de despliegue)
• La capacidad para aceptar cualquier dato y convertirlo en algo útil y procesable con mucha rapidez (la implementación de la POC, de inicio a fin, tardó aproximadamente 3 días completos, incluyendo todas las tareas mencionadas en esta publicación: parseo, dashboards, enriquecimiento, el marco de trabajo de alertas, etc.)
• El hecho de poder hacer esto en paralelo con todos los procesos existentes, sin interrupciones

Cómo actualizar

Después de algunas semanas en producción, Elastic lanzó una actualización. Como ya había actualizado despliegues grandes de Elastic con X-Pack, sentía curiosidad por ver cómo se realizaría con su plataforma de cloud. Resultó ser tan sencillo como seleccionar la versión nueva en un menú desplegable. Todo lo demás se realizó automáticamente, sin interrupciones.

Conclusión

Obviamente, nuestro viaje con Elastic no terminó aquí. Agregamos constantemente más fuentes de datos, más enriquecimiento (como la correlación con nuestros sistemas de RR. HH. para obtener datos sobre las vacaciones de los usuarios y los sistemas de acceso físico para saber si hay alguien en el edificio y si debería estar ahí o no) y más alertas sobre la marcha basadas en las amenazas y actividad maliciosa descubiertas recientemente. También trabajamos para integrar herramientas internas adicionales que usamos.

Nos entusiasma el futuro de la analítica de seguridad con Elastic. Con cada actualización, Elastic lanza componentes adicionales que facilitan la vida de los analistas y hacen que sus trabajos sean más satisfactorios. Además, estamos igual de entusiasmados por las próximas actualizaciones en Elastic Cloud. Sin duda alguna, RS2 seguirá beneficiándose de los amplios conjuntos de características, no solo en la analítica de seguridad, sino en toda la organización.