En el post de la semana pasada realice algunas preguntas sobre la importancia que se le otorga a los logs.
Veo en general que este tema es dejado de lado en la mayoría de los blogs de seguridad, quienes apuntan mas a informar sobre vulnerabilidades y no dedican mucho tiempo sobre aspectos de management o infraestructura.
Los logs son fundamentales para realizar el análisis forense luego de sufrir un ataque, incluso sirven como herramienta de detección de ataques y diagnostico de problemas, aunque es una herramienta reactiva nos brindan una capa mas de protección.
Pensemos que muchas veces encontrar patrones de ataques en algunas empresas es como buscar una aguja en un pajar.
En mi ultimo empleo teniamos los siguientes numeros de eventos :
Estos equipos no estaban correlacionando los eventos centralmente.
Imaginen encontrar un problema dentro de ese volumen de eventos !!!
La gestion de logs es un requisito necesario para cumplir con diferentes regulaciones , entre ellas SOX, PCI, HIPAA, y auditorías corporativas, COBIT, ISO/IEC 17999/27001.
La siguiente información esta basada en las recomendaciones del NIST (National Institute of Standards and Technology) publicadas bajo el nombre de Guide to Computer Security Log Management.
El plan para implementar una infraestructura de log management esta compuesto por los siguientes puntos :
- Definiciónde Roles y Responsabilidades .
- Establecer una politica de log management.
- Asegurarnos que las políticas pueden ser cumplidas.
- Diseñar la arquitectura de log management.
Dependiendo del tamaño de la organización, esto puede variar, en general los administradores de red y sistemas son quienes se encargan de configurar los dispositivos y monitorear los logs regularmente.
Los responsables de seguridad tienen la misma responsabilidad sobre los dispositivos de seguridad y sobre la infraestructura de log management.
Por supuesto que en una organización pequeña, en gral el administrador de red y de sistemas tienen que coordinar esto y tratar de contar con una herramienta lo mas automatizada para poder descargar en parte ciertas tareas repetitivas.
Establecer una politica de log management.
La política de log management debe establecer claramente criterios que definan la generación , transmisión, almacenamiento , destrucción y análisis de los eventos que son almacenados en los archivos de logs.
En algunos casos esta política basara estos criterios en las normativas a la cual se encuentre sujeta la empresa.
Asegurarnos que las politicas pueden ser cumplidas.
Una política demasiado ambiciosa puede tener el efecto contrario al esperado. Es decir si intentamos administrar los logs de todos los equipos disponibles, seguramente la saturación creara cuellos de botella que terminaran perjudicando el proyecto.
Un análisis de riesgo nos permitira detectar cuales son los equipos mas críticos a los cuales debemos prestar mayor atención.
Arquitectura
Una arquitectura típica de manejo de logs esta compuesta por tres niveles
Generación. Corresponde a la primer capa en donde los eventos son generados, los mismos pueden ser generados por aplicaciones hacia el log server o por agentes que convierten los eventos de ciertas aplicaciones en entradas de log.
Almacenamiento y Analisis : En la segunda capa se produce el almacenamiento el análisis y correlacion de los eventos. Podemos tener varios servers de logs y almacenarse en BD o archivos.
Aqui se pueden setear triggers que ante ciertas condiciones (p. ej: mas de tres intentos fallidos en el logging de un administrador ) disparen alarmas.
Monitoreo de logs : La ultima capa se encarga de visualizar los eventos que disparan los triggers y generar estadísticas.
No todas las organizaciones pueden tener una infraestructura para el manejo de logs, aquellas que no cuentan con el presupuesto adecuado, como dije anteriormente, un análisis de riesgo ayudara a encontrar los activos mas críticos a proteger.
Otros aspectos a tener en cuenta es contar con una red especifica para los logs, ya que en caso de una intrusión, estos pueden quedar expuestos o en otro caso pueden sufrir una denegación de servicio y también muy importante es contar con un Time Server para sincronizar la hora de todos los dispositivos.
Por supuesto que es recomendable aislar el Log Server en una DMZ detras de un firewall y solamente habilitar los ports de administración ( ssh , ssl ) y de syslog.
Para los equipos que se encuentren en redes publicas una solucion posible es la que vimos en este post, mediante la utilización de un cable que solo permita el ingreso de información.
En el proyecto NeMO ( del cual hable en este post )la infraestructura de logs implementada fue la siguiente :
Era una arquitectura con logs servers distribuidos en diferentes paises, los cuales alimentaban un log server central. Las comunicaciones entre logs servers se encontraban encriptadas por medio de ssh utilizando certificados digitales. El log server central tenia las reglas de alerta según una matriz de criticidad. La consola de administración mostraba los eventos mas criticos.
Diariamente el server de log central generaba un documento con los eventos mas interesantes.
Todo esto fue realizado con software open source, por lo tanto no hay motivos presupuestarios ( salvo los costos de un server, aunque se puede utilizar un server de aplicaciones que este siendo reemplazado )para no tener este tipo de soluciones.
Siguiendo con los puntos que destaca NIST en una infraestructura de log management, las siguientes son las funciones que debe cumplir :
Log parsing : Consiste en extraer los datos relevantes de un log para su almacenado o como input en otro proceso.
Event filtering : Puede aplicarse en caso de búsquedas de ciertos eventos o para descartar eventos pocos significativos. El tipo de filtrado dependerá que tan rigurosos seremos al momento de almacenar los logs. Por ejemplo podemos optar por almacenar logs de eventos de un Firewall que afecten solamente a IP publicas en uso y no guardar los eventos que lleguen a IP's publicas que no esten publicadas.
Event aggregation: Se utiliza para reducir el tamaño de los logs, cuando un mismo evento se repite varias veces.
Log rotation : Es el acto de crear un nuevo log cuando se cumple cierta condicion, por ejemplo supero un tamaño, cambio la fecha.
Log retention : Es el acto de almacenar un log durante un periodo de tiempo en algún dispositivo o medio externo, en esto tienen impacto en algunos casos las leyes o regulaciones.
Log compression : Se utiliza para reducir el espacio ocupado por el log, se realiza en muchos casos al momento de la rotacion.
Log conversion : En algunos casos se utiliza para almacenar los logs en otro formato, por ejemplo de un archivo plano a una Base de Datos.
Log normalization : Se utiliza para convertir ciertos campos en un tipo de dato en particular. En gral es usado para normalizar fechas y horas.
Log file integrity checking : Luego de realizar la rotación se calcula un Hash para asegurarnos de poder detectar modificaciones a los logs almacenados.
Event correlation : La correlacion de eventos es para detectar un patron de eventos, por ejemplo si tenemos que una misma IP de origen realizo un por scanning en una serie de servers y luego intento realizar un logging en un puerto , una correlacion nos indicaría el camino que siguio el intruso para intentar acceder a nuestros sistemas.
Log viewing y Log reporting : Es la capacidad que tiene un sistema de entregarnos la información en un formato facial de entender. Esto puede ser por medio de reportes o por medio de un dashboard en tiempo real.
Por ultimo debo recalcar que contar con un sistema de logs y no tener tiempo para poder verificarlos es casi tan peligroso como no tener logs.
Por experiencia note muchas veces de sistemas que enviar alarmas por mail, que luego de un deslumbramiento inicial, luego de dos semanas de recibir 40 mails diarios de un sistema mal configurado, se opta por redirigir los mails a una carpeta y no verlos hasta que se llena el buzón.
En otros posts vamos a ver algunas herramientas para armar una infraestructura de log management básica.
1 comment:
Este tipo de post me dan nostalgia.
Antes era Tecnico y Administrador. Ahora soy "Ejecutivo de Cuentas" :(
Son tan lindas estas cosas.
Gracias por los recuerdos y por la info que nunca está de más.
Post a Comment