Conoce por qué son importantes los logs de eventos y cómo afectan a la efectividad y fiabilidad del SOC y, por tanto, a la protección del ecosistema SIEM.
|
Índice de Contenidos: |
Al implementar un Centro de Operaciones de Seguridad o SOC, parece que sólo se trata de normalizar y hacer llegar los eventos al SIEM (información de seguridad y gestión de eventos). A partir de ahí, los casos de uso y los analistas harán su “magia” para detectar y advertir de hechos maliciosos y dar la señal de alarma para neutralizarlos.
Sin embargo, la eficacia del SOC no sólo depende de estos aspectos. La cantidad y fiabilidad de los logs que se procesan y de los posibles ataques que se pueden producir sobre sus orígenes y motor de correlación son factores muy importantes.
La activación de las auditorías y su protección son aspectos importantes y así queda recogido en los requisitos de todos los estándares, regulaciones y recomendaciones asociadas a ciberseguridad.
¿En qué consisten los logs de eventos?
Los logs de eventos (o registros de eventos) no sólo son dónde acudir para averiguar por qué han fallado los sistemas TIC. En ciberseguridad son, en la práctica, las balizas utilizadas para determinar que todo sucede con normalidad.
¿Por qué son tan importantes los logs?
Los ciberdelincuentes lo saben y en la planificación de sus ataques incluyen tácticas y técnicas con las que cegar o interferir este radar, con una complejidad y elaboración que dependerá del alcance del ataque.
Es más, en OneseQ solemos presentar a los clientes, en los informes de seguimiento, resultados sobre el análisis de cientos de millones de eventos de logs recogidos sobre sus sistemas. Un volumen de información que permite conocer en detalle y de continuo qué está ocurriendo.
Ahora bien, las alertas que se generan y las notificaciones sobre las anomalías que se detectan sólo son relevantes si está asegurada la fiabilidad de esos millones de datos procesados y el análisis se produce a tiempo. La fiabilidad que puede ofrecer el SOC, depende de la protección que se haga de todos los componentes que participan en el sistema de alerta temprana implementado.
Protección de los registros de eventos
Control de accesos a registros
La primera medida de protección de los eventos que se debe aplicar es el control de acceso a esos registros en las fuentes. Para evitar manipulaciones intencionadas o accidentales.
Sólo deben acceder a los mismos aquellos usuarios encargados de su revisión y operación, diferenciando por perfiles. Conviene asignar acceso de lectura al personal de soporte, técnicos de nivel 1 y nivel 2. Acceso completo a los administradores de cada sistema.
Y en este control de acceso, no hay que olvidar los archivos donde residen físicamente los eventos registrados. Aunque de manera predeterminada estos ficheros tienen un acceso limitado, una incorrecta asignación de privilegios o una incorrecta herencia de privilegios en archivo pueden dejarlos accesibles.
Un acceso controlado que debe ser revisado para los archivos de eventos de aplicaciones, principalmente cuando estas son de diseño propio, ya que la ubicación de estos archivos dependerá de sus desarrolladores.
Reenviadores forwarders
Otro componente habitual en el ecosistema SIEM son los reenviadores forwarders. Un equipo, físico o virtual, que se encarga de recopilar los eventos procedentes de una o distintas fuentes para su posterior reenvío al motor de alertas del SIEM.
Para estos equipos hay que considerar, primero, su ubicación. Conviene desplegarlos en una subred independiente con reglas de conexión muy estrictas, para evitar que puedan estar expuestos a las mismas amenazas que los sistemas de los que recopilan eventos y algún actor malicioso pueda manipularlos, permitiendo la recepción y reenvío de logs.
Lo ideal, una subred específica. Si no es posible o resulta una arquitectura complicada, hay que sopesar colocar los reenviadores en una subred de gestión, normalmente, más protegidas que otras subredes, o, incluso, la DMZ, según las necesidades de conexión hacia un correlador exterior que puedan darse.
La configuración de la estructura y gestión de SIEM se debe abordar como parte de la arquitectura de seguridad de la organización. Requiere prestarle atención y cuidado para conseguir una adecuada integración en la misma.
Bastionado de logs
También hay que considerar su bastionado (hardening). Aunque su función es simple y sólo requieren inicios de sesión interactivos para mantenimiento, deben reforzarse su seguridad a todos los niveles.
Sólo debe instalarse el software que estrictamente se necesite, limitar quien puede iniciar sesión en ellos, instalar antivirus y, por supuesto, mantenerlos actualizados.
Hay publicadas distintas guías que dan pautas adaptables para reforzar la seguridad en estos componentes y que cubren distintos sistemas operativos. Como son las guías CCN-STIC-600 publicadas por el Centro Criptográfico Nacional (CCN) o las asociadas al programa del gobierno estadounidense conocido como NIST SP 800-70.
Monitorización de eventos
Y monitorizar su estado. Si los reenviadores, por alguna razón, dejan de lanzar logs al SIEM se pierde la ventaja de la detección temprana. Falta de espacio en disco para acumular los eventos antes de su reenvío y fallos de conexión, suelen ser los problemas más habituales en los forwarders.
La monitorización con herramientas tipo Nagios o PRTG es fácil y evita que el SIEM quede “ciego” más tiempo del necesario y que se pierdan eventos que pueden ser relevantes.
Proteger la correlación de logs
El último componente del ecosistema de alerta temprana, el correlador, también requiere que sea protegido. Principalmente en su disponibilidad. Y diferenciando la ingesta de eventos, por un lado, y el motor de correlación, por otro. Aunque depende de la arquitectura de cada solución, lo normal es que estas capacidades sean montadas con dos componentes independientes que interactúan entre ellos. Componentes que conviene montar en nodos independientes.
En la ingesta de eventos, el colector, lo ideal es considerar mecanismos de alta disponibilidad y balanceo de carga. Aunque no es imprescindible, es aconsejable. La posibilidad de mantener durante algún tiempo los eventos en las fuentes y en forwarders, si no hay contacto con el colector, proporciona un margen temporal suficiente para implementar medidas de recuperación de este componente, que sean más asequibles, técnica y económicamente, a la alta disponibilidad. Un plan con tiempos de recuperación bajos, suele ser suficiente.
Si el colector está expuesto en Internet, también debe considerarse la posibilidad de ataques de denegación de servicio (DoS) en cualquiera de las técnicas conocidas. Para reducir este riesgo, suele ser habitual ubicar el colector detrás de un cortafuegos (firewall) convencional o web, con capacidad para detectar y filtrar posibles inundaciones. También conviene que el filtrado hacia el colector, considere sólo las conexiones desde las fuentes conocidas de donde ha de recibir los eventos.
En este escenario, la recepción de eventos a través de Internet, las conexiones entre fuentes y colector deben estar protegidas para evitar interceptaciones y suplantaciones. Bien utilizando protocolos seguros de conexión como TLS, con certificados digitales. Bien estableciendo conexiones VPN. La opción más segura es la conexión VPN. Aquí es donde montar la recolección y reenvío de logs a través de un único punto, forwarder, toma ventaja, puesto que simplifica la securización del envío de eventos.
Para el motor de correlación, con menos exposición a Internet, la principal preocupación es la disponibilidad, como se ha comentado. Este componente, sí es más que recomendable que tenga implementados mecanismos de alta disponibilidad, que dependerán de la arquitectura y posibilidades de cada solución.
Tanto para el colector como para el correlador, no debe descuidarse su bastionado y ubicación. Importante que se localicen en una subred propia. Si estos componentes van a “cajas” distintas, no está de más que se coloquen en subredes diferentes, con reglas de conexión entre ellos que limiten su nivel de exposición.
Al igual de lo comentado para los forwarders, colector y correlador deben configurarse para reforzar su seguridad, instalar el software mínimo e imprescindible para su función, limitar el inicio de sesión interactivo, etc.
Ciberataques comunes al SIEM
Los ciberdelincuentes también son conscientes de la importancia de los logs para la detección de sus fechorías y su incriminación. Por ello recurren a distintas tretas con las que complicar la detección de las acciones que llevan a cabo para comprometer los sistemas y borrar cualquier rastro de ese compromiso.
Una de las tácticas que tratará de emplear un atacante para ello es la desactivación de las políticas de auditoría del sistema comprometido. Utilizará distintas técnicas, pero el SIEM podrá advertir la situación si se definen los casos de uso que monitoricen los eventos relacionados con estos cambios. Por ejemplo, en Windows, se deben monitorizarse los eventos identificados con el ID 4711 a 4719 y otros relacionados, como puede ser el evento con ID 4817.
El atacante, también podrá intentar borrar los eventos ya registrados. Para detectar estas situaciones se deben definir reglas de monitorización que adviertan sobre esas acciones, que en Windows se pueden identificar por eventos que tengan como ID 1102.
Si el atacante no interviene directamente sobre los registros de eventos, puede intentar otras tácticas. Como la manipulación del reloj del sistema para que la correlación en el SIEM no funcione adecuadamente. El cambio de hora del sistema, también es relevante como indicio de un comportamiento anómalo. La supervisión de los eventos con ID 4616 en Windows, revelan estas actividades que conviene revise un analista.
Ataques DDoS dirigidos al SIEM
Si de ofuscar el correlador se trata, se pueden identificar ataques de denegación de servicio (DDoS) contra el SIEM y, por extensión, contra los analistas. El objetivo es tratar de generar un número elevado de eventos adulterados que retrase el proceso del SIEM, que confundan o atraiga la atención de los analistas que tienen que tratar gran cantidad de “falsos positivos”, de forma que las alarmas relevantes, pasen desapercibidas y el atacante pueda perpetrar sus acciones.
La recepción repentina de un número excesivo de eventos, la aparición de muchas alertas que son descartadas, superior a lo esperado, o advertencias de la plataforma SIEM sobre los eventos malformados inesperados, deben poner a los operadores en alerta sobre un posible ataque de ofuscación y de la posible materialización de un ataque sobre el sistema monitorizado.
Integración del SOC en la arquitectura de seguridad
Como se ve, la implementación del SOC no debe ser planteada únicamente como el despliegue de los distintos componentes que lo conforman de manera eficiente y operado por analistas capacitados. Descontado el despliegue de esos componentes, el grado de eficacia del SOC es directamente proporcional al grado de aseguramiento de los eventos analizados y disponibilidad del motor de análisis.
La protección del ecosistema SIEM, es un factor que añade complejidad a la implementación de un SOC y puede hacer desistir de su implementación, sobre todo, en aquellas organizaciones que no cuentan con una capacidad técnica y operativa clara para asumirla. Esta circunstancia, no obstante, no debe ser la causa de abandonar el proyecto de contar con un SOC, si la organización considera en su postura de seguridad que es conveniente. Es cuando debe valorarse la externalización de los servicios de SOC. El proveedor es quien se ocupa de resolver cualquier complejidad técnica o de arquitectura y ofrecer una solución viable técnica y económica.
