La mayoría de las compañías modernas se encuentran con desafíos de seguridad de la información todos los días, que van desde ataques dirigidos externos hasta fugas internas, a pesar de usar varios enfoques y herramientas de seguridad de la información. La Tecnología de la Información (IT) está evolucionando rápidamente para mantenerse dentro del terreno de las amenazas; pero nuevos enfoques y herramientas significan nuevas vulnerabilidades.Los perpetradores están volviéndose más astutos y más rápidos. La clásica triada de confidencialidad, integridad y disponibilidad (CID) no ha sido suficiente para dirigir estos desafíos, especialmente cuando ocurren incidentes de seguridad de la información (i.e., la triada CID ha sido vulnerada total o parcialmente).
Reportes analíticos globales encuentran un creciente número de incidentes anuales y un incremento en la sofisticación1 de los incidentes. En otras palabras, los incidentes han sucedido, están sucediendo y sucederán. Para una detección oportuna de eventos y un trabajo profundo de forense, es necesario expandir las habilidades de seguridad de la información y la triada CID, para asegurar responsabilidades. Sin embargo, el registro de responsabilidades crea millones de eventos de seguridad;2 por lo que, es importante asegurar una efectiva administración de la información de seguridad y de eventos (SIEM)3 dentro de un sistema de administración de seguridad de la información (ISMS).4
Este artículo presenta un desequilibrio existente entre problemas técnicos y aspectos de proceso relacionados al SIEM.
Proceso SIEM
Se debe ser consciente que antes de implementar la SIEM, es necesario establecer la base del ISMS, que incluirá, considerando el compromiso de la dirección global, un inventario de activos y una categorización y evaluación de riesgos. El proceso SIEM puede ser implementado cuando las herramientas corporativas de seguridad requeridas son obtenidas y el nivel del modelo de capacidad del proceso no es más bajo que el proceso administrado definido en COBIT 5.5
El Proceso SIEM consiste en seguir un ciclo de cinco pasos (figura 1).
El enfoque SIEM está basado en el ciclo de planificar-hacer-verificar-actuar (PDCA). Este artículo se focaliza en el paso del ciclo SIEM: establecimiento de políticas.
SIEM Establecimiento de Políticas
La alta dirección debe demostrar su compromiso hacia el ISMS, incluyendo la SIEM, mediante el aseguramiento de la política de la SIEM y que es compatibles con la dirección de la compañía, su contexto y el enfoque de riesgo. Usualmente, el gerente de seguridad de la información (CISO) prepara esta política interna y obtiene la aprobación de todos los interesados. Esta política debe ser mapeada contra otras políticas internas existentes, así como definir una lista detallada de eventos dentro de estándares o líneas base para servidores y herramientas de red.
La política SIEM debe contener los siguientes componentes básicos:
- Propósito de la política
- Alcance de la infraestructura SIEM
- Responsabilidades de los individuos involucrados
- Cumplimiento
Propósito
El propósito describe la necesidad de tener la política y debe confiar en y alinearse a las actividades del negocio, objetivos y contexto. Existen muchas razones para desarrollar una política SIEM. Algunas de las razones incluyen:
- Mantener una amplia visión de seguridad de TI
- Desarrollar la detección de incidentes
- Mejorar los trabajos de forense y analítica de la seguridad de TI
- Establecer el cumplimiento
Alcance
El alcance es la parte más grande de la política SIEM debido a la descripción de la infraestructura SIEM. La infraestructura SIEM es más que un solo sistema SIEM. Comúnmente se malentiende que un sistema SIEM es el componente esencial de la infraestructura SIEM. El sistema SIEM es una solución tecnológica y es sólo un componente de la infraestructura SIEM. La infraestructura SIEM consiste en diferentes orígenes de eventos, almacenamiento de eventos, herramientas de análisis y una consola de monitoreo, y también incluye proveedores de información externa, e.g., McAfee Global Threat Intelligence, RSA FirstWatch y Kaspersky Security Intelligence Services. Las fuentes de eventos son un componente esencial de la infraestructura SIEM ya que la fuente del evento deja datos dentro de pistas de auditoría (i.e., eventos registrados). Sin eventos registrados, un SIEM es inútil.
Una fuente de eventos es cualquier software o firmware (un conjunto de software y hardware), lo cual puede incluir:
- Firewalls (FW)
- Sistemas de detección y/o protección de intrusiones a la red y/o hosts
- Herramientas de redes privadas virtuales (VPN)
- Sistemas de administración unificada de amenazas (UTM)
- Autoridad de certificación (CA)
- Herramientas de cifrado
- Herramientas de seguridad en dispositivos finales de red (endpoint)
- Antivirus (AV) tools
- Escáners de Vulnerabilidades (VS)
- Sistemas de prevención de pérdida de datos (DLP)
- Sistemas de administración de identidades y acceso (IAM)
- Software de sistema (e.g., sistema operativo, hipervisor)
- Software aplicativo (e.g., sistema de administración de base de datos, servidor web)
Existen dos criterios principales que determinan si una pieza del equipo es la fuente del evento:
- Capacidad de registrar (logging)
- Capacidad de proveer acceso a los datos registrados en los archivos de bitácora
Si el primer criterio no es posible, el equipo en interrogante no es una fuente de evento. Si el segundo criterio no es posible, el equipo es una fuente de evento aislada. El componente principal de las fuentes de eventos son las herramientas de seguridad, las cuales son soluciones empresariales que cumplen con los dos factores principales mencionados anteriormente (i.e., capacidad de registrar y capacidad de proveer acceso a los datos registrados en los archivos de bitácora). Herramientas tales como FW, IDS/IPS o UTM son herramientas de seguridad de red.
Existe un tipo de fuente de eventos separado que provee paquetes de datos de red. Este tipo de herramienta incluye analizadores de puertos conmutados (SPAN ports), soluciones de puntos de pruebas de acceso (TAP) y herramientas para la captura de paquetes a través de la escucha de la red (sniffers). Los paquetes de red pueden ser más útiles que los datos registrados en archivos de bitácora.
Brian Girardi, vicepresidente de arquitectura de productos e investigación en RSA, dijo “Necesitamos fuentes de datos más completas y visibilidad en los datos de red, lo que significa que el modo en que almacenamos, manejamos, procesamos y modelamos los datos debe cambiar. Necesitamos hacerlos más consumibles -no solo más datos, sino mejores datos”. Para crear datos más consumibles, las siguientes preguntas deben ser consideradas:
- ¿Dónde están los datos recolectados?
- ¿Qué es la recolección de datos?
Los siguientes pasos pueden proveer a las empresas de alguna dirección al contestar las preguntas anteriores:
- Segmentar la red en consistencia con los grupos de activos y niveles críticos, i.e., definir zonas de confianza (e.g., segmento interno, segmento de preproducción) y zonas críticas (e.g., el segmento de la industria del pago de tarjetas, la zona desmilitarizada).
- Definir puntos de interconexión entre zonas.
- Los datos deben fluir relativamente libre dentro de las zonas de confianza, mientras que los datos fluyendo hacia dentro y hacia afuera de la zona de confianza (puntos de interconexión) requiere más control.
Por ende, los datos deben ser recolectados:
- Dentro de zonas de confianza en el nivel básico (archivos de bitácora)
- Dentro de zonas críticas en el nivel avanzado (primero, archivos de bitácora; segundo, paquetes de datos de red)
- Dentro de puntos de interconexión en el nivel avanzado (primero, paquetes de datos de red; segundo, archivos de bitácora)
Al discutir qué es lo que está siendo recolectado, uno debe recordar que el primer principio de la recolección es que recolectar todos los datos no es el objetivo principal del SIEM. Los datos recolectados deben ser valiosos y los datos no utilizados no son requeridos y deben ser descartados. Los datos no utilizados no son de valor y desperdician el tiempo del equipo SIEM.
Uno debe recordar que la recolección de una línea de 100 Mbps (paquetes de red) equivale a 1 terabyte (TB) de almacenamiento por día. No todas las organizaciones están preparadas para gastar lo suficiente para desarrollar este tipo de capacidad de almacenamiento. Para administrar de mejor manera esta gran cantidad de requerimientos de almacenamiento, uno debe considerar lo siguiente:
- Familiarizarse con la línea base y eventos normales (crear un perfil de asuntos cotidianos de negocio del día, definir los servicios, fuentes y destinos principales).
- Filtrar el tráfico de red conocido, tanto bueno como no deseado (permitido por políticas de seguridad de la información), i.e., reducir la cantidad de información, pero que no solo se descarte o filtre porque acumula espacio.
- Se debe focalizar en la seguridad de la información crítica. Esto puede proveer mayor visibilidad hacia los datos desconocidos o que no son de confianza.
- Se debe focalizar en los lugares donde no hay controles de seguridad de la información.
- Frecuentemente (e.g., mensualmente) se debe revisar las líneas base y los perfiles definidos.
Responsabilidades
Mientras que en la alta administración debería recaer la responsabilidad general de la política SIEM, un dueño del proceso SIEM debe ser asignado. Este dueño de proceso no tiene que ser el gerente de seguridad de la información (CISO). La alta administración debe definir la estructura del equipo SIEM.
Cumplimiento
El cumplimiento define cómo juzgar la efectividad de una política SIEM (i.e., que tan bien está funcionando) y qué sucede cuando se viola la política (la sanción). Algunas veces las métricas y los indicadores clave de desempeño son descritos en esta parte.
Conclusión
El SIEM se ha convertido en el corazón de un ISMS y de centros de operación de seguridad (SOC), pero no es sabio confiar tan solo en los aspectos técnicos del SIEM. La política SIEM es esencial para asegurar la efectividad del SIEM dentro de un ISMS. El tiempo utilizado para el desarrollo de la política SIEM vale la pena; ahorrará esfuerzo en pasos futuros. La parte más grande de la política-el alcance-merece especial atención, y es importante recordar que la base de la infraestructura son las fuentes de eventos y no el sistema SIEM.
Notas
1 PricewaterhouseCoopers, The Global State of Information Security Survey 2016, 2015, www.pwc.com/gsiss2015
2 A security event is a change in or retention of the status, which has implications for IS, management, the health of the component(s) of IT infrastructure and/or ISMS of a company. It also affects the audit trail (file, database table or some other location) information for this event.
3 SIEM is a part of the ISMS of a company, including technological components, processes and staff.
4 ISMS is a part of the overall management system of a company, based on a business risk approach, to establish, implement, operate, monitor, review, maintain and improve IS.
5 ISACA, COBIT 5, USA, 2012, www.isaca.org/cobit
Aleksandr Kuznetcov, CISM
Es jefe del departamento de seguridad de la información en el centro de investigación y desarrollo en Vulkan LLP. En este cargo es que dirige el equipo de implementación información de seguridad y gestión de eventos (SIEM). Él tiene 10 años de experiencia en seguridad de la información y cinco años de experiencia en el SIEM. Él es un autor activo y orador público en sus áreas de especialización. También está llevando a cabo un postgrado en la Universidad Financiera (Moscú, Rusia).