guÍa metodolÓgica para la gestiÓn ......1 guÍa metodolÓgica para la gestiÓn centralizada de...
TRANSCRIPT
1
GUÍA METODOLÓGICA PARA LA GESTIÓN CENTRALIZADA DE REGISTROS DE SEGURIDAD A TRAVÉS DE UN SIEM
JULIAN DAVID AVELLA CORONADO COD 660407
LEONARDO FABIO CALDERON BARRIOS COD 660405
CRISTIAN ANDRÉS MATEUS DÍAZ COD 660399
UNIVERSIDAD CATÓLICA DE COLOMBIA
FACULTAD DE INGENIERÍA
PROGRAMA DE ESPECIALIZACIÓN EN SEGURIDAD DE LA INFORMACIÓN
BOGOTÁ D.C – 2015
2
GUÍA METODOLÓGICA PARA LA GESTIÓN CENTRALIZADA DE REGISTROS DE SEGURIDAD A TRAVÉS DE UN SIEM
JULIAN DAVID AVELLA CORONADO
LEONARDO FABIO CALDERON BARRIOS
CRISTIAN ANDRÉS MATEUS DÍAZ
Trabajo de grado para obtener el título de especialista en Seguridad en Redes.
ASESOR: JAVIER VELANDIA
UNIVERSIDAD CATÓLICA DE COLOMBIA
FACULTAD DE INGENIERÍA
PROGRAMA DE ESPECIALIZACIÓN EN SEGURIDAD DE LA INFORMACIÓN
BOGOTÁ D.C – 2015
3
4
TABLA DE CONTENIDO
pág.
TABLA DE CONTENIDO .......................................................................................................................... 4
INTRODUCCIÓN ....................................................................................................................................... 9
1. GENERALIDADES DEL TRABAJO DE GRADO .......................................................... 10
1.1 LÍNEA DE INVESTIGACIÓN........................................................................................................... 10 1.2 PLANTEAMIENTO DEL PROBLEMA .............................................................................................. 10
1.2.1 Antecedentes del problema ......................................................................................... 10 1.3 JUSTIFICACIÓN ........................................................................................................................... 12 1.4 OBJETIVOS ................................................................................................................................. 13
1.4.1 Objetivo general .......................................................................................................... 13
2. MARCOS DE REFERENCIA ............................................................................................ 14
2.1 MARCO CONCEPTUAL ......................................................................................................... 14 2.2 MARCO TEÓRICO ........................................................................................................................ 16 2.3 MARCO LEGAL ....................................................................................................................... 18
3. METODOLOGÍA ................................................................................................................ 19
3.1 FASES DEL TRABAJO DE GRADO ..................................................................................... 19
4. SELECCIÓN MODELO DE MEJORES PRACTICAS DE GESTIÓN DE LOGS ......... 21
4.1 TECNOLOGÍA, PROCEDIMIENTOS Y POLÍTICAS PARA EL REGISTRO DEL LOG . 23 4.2 CAPTURA Y GENERACIÓN DE LOGS ............................................................................... 24 4.3 ALMACENAMIENTO Y RETENCIÓN DE LOGS ................................................................ 25 4.4 ANÁLISIS DE LOGS ............................................................................................................... 27 4.5 SEGURIDAD Y PROTECCIÓN DE LOGS ........................................................................... 28 4.6 MODELO BUENAS PRACTICAS GESTIÓN DE LOGS .................................................... 29
5. SELECCIÓN DE HERRAMIENTA SIEM LIBRE ............................................................ 31
5.1 DESCRIPCIÓN DE HERRAMIENTAS SIEM ...................................................................... 31 5.1.2 OSSEC ........................................................................................................................ 33 5.1.3 OSSIM ........................................................................................................................ 34 5.1.4 GRAYLOG. ................................................................................................................. 34
5.2 COMPARATIVO HERRAMIENTAS SIEM ........................................................................... 36
6. ESTRUCTURA DE LA GUÍA METODOLÓGICA ........................................................... 38
6.1.1 Definición del alcance ................................................................................................ 39 6.1.3 Infraestructura gestión de Logs. ................................................................................ 41 6.1.4 Generación y transmisión .......................................................................................... 44 6.1.5 Retención y almacenamiento de logs ......................................................................... 45 6.1.6 Análisis automático y correlación .............................................................................. 47
5
6.1.7 Seguridad de los registros de logs .............................................................................. 48 6.1.8 Notificación de alertas................................................................................................ 49 6.1.9 Análisis de reportes .................................................................................................... 49 6.1.11 Eliminación de logs .................................................................................................... 51
7 DEFINICIÓN E IMPLEMENTACIÓN DE CASO DE PRUEBA ...................................... 52
7.1 DEFINICIÓN E IMPLEMENTACIÓN DE CASO DE PRUEBA.............................................................. 52 7.2 DESCRIPCIÓN DEL AMBIENTE ..................................................................................................... 53 7.3 DESARROLLO CASO DE PRUEBA ................................................................................................ 55
7.3.1 Configuración y funcionamiento OSSIM. ................................................................ 55
8. CONCLUSIONES .............................................................................................................. 58
FIGURAS……………………………………………………………………………………………6 CUADROS…………………………………………………………………………………………..7 ANEXOS…………………………………………………………………………………………….8
6
FIGURAS
FIGURA 1..…..……………………………………………………………………………..36
FIGURA 2........……………………………………………………………………………..54
7
CUADROS
CUADRO 1…..……………………………………………………………………………..36
CUADRO 2......……………………………………………………………………………..54
CUADRO 3..………………………………………………………………………………..54
CUADRO 4..………………………………………………………………………………..56
8
ANEXOS
ANEXO A…………………………………………………………………………………..62
ANEXO B…………………………………………………………………………………..63
ANEXO C…………………………………………………………………………………..64
ANEXO D…………………………………………………………………………………..66
ANEXO E…………………………………………………………………………………...67
ANEXO F…………………………………………………………………………………...69
ANEXO G…………………………………………………………………………………..70
ANEXO H…………………………………………………………………………………..71
ANEXO I................................................................................................................................72
ANEXO J……………………………………………………………………………………76
ANEXO K…………………………………………………………………………………..85
9
INTRODUCCIÓN
La gestión centralizada de registros es un tema que se ha desarrollado en el último
tiempo con la evolución de las TI, a pesar que ha tenido una investigación por
instituciones internacionales, no ha sido tan valorado ni reconocido como una
solución de apoyo a la administración y soporte de la infraestructura de TI en las
empresas. El auge y la importancia que ha obtenido la seguridad de la
información, permite el desarrollo de nuevas tecnologías como los SIEM (Security
Information Event Management) que impulsa y renueva el desarrollo en la gestión
centralizada de logs mediante el tratamiento que se realiza sobre estos.
10
1. GENERALIDADES DEL TRABAJO DE GRADO
En el presente capitulo se describen las razones y en si el problema identificado,
que llevaron al desarrollo del presente trabajo, adicional se plantean caramente los
objetivos del mismo, para enfocar al lector sobre lo plasmado en los siguientes
capítulos.
1.1 LÍNEA DE INVESTIGACIÓN
Con el enfoque desarrollado en este trabajo de investigación, se da a conocer una
ayuda a empresas que no poseen recursos y conocimiento para el análisis
centralizado de los registros de seguridad generados, esta temática se inscribe en
la línea de “Software inteligente y convergencia tecnológica” avalada por la
Universidad Católica de Colombia, teniendo en cuenta que al realizar el presente
estudio, se pueden identificar variables que colaboran en la toma de acciones y
decisiones preventivas y correctivas de ámbito técnico, tecnológico y seguridad de
la información, que busca reducir las vulnerabilidades de las tecnologías de la
información de la compañías.
1.2 PLANTEAMIENTO DEL PROBLEMA
1.2.1 Antecedentes del problema
Las herramientas y aplicaciones tecnológicas, generan registros de seguridad que
normalmente son almacenados localmente y contienen información acerca de los estados,
comportamientos y cambios que ocurren en cada dispositivo.
Estos registros ayudan a encontrar vulnerabilidades, saber lo que está ocurriendo
con los sistemas de información a través de toda la infraestructura de TI de una
organización, garantizar y actualizar políticas de seguridad y realizar trazabilidad
de algún proceso específico. Aunque es posible hacer un análisis local de los
registros, en cada uno de las fuentes generadoras por separado, en muchas
ocasiones no se evidencia un comportamiento asociando los registros de varios
dispositivos en conjunto, porque no hay un conocimiento sólido, para validar las
interacciones que puedan tener entre los sistemas de información.
11
Por lo cual se recomienda el uso de un Sistema de Administración de Eventos y
Seguridad de la Información - SIEM por sus siglas en inglés (Security Information
Event Management) para realizar la correlación y análisis centralizado de estos
registros.
Desafortunadamente, muy pocas organizaciones aprovechan el valor que tiene la
gestión de estos logs, para evidenciar riesgos, vulnerabilidades o trazabilidad en
incidentes, esto basado en la experiencia y conocimiento sobre algunas empresas,
además de estadísticas y estudios realizados por empresas, institutos y
organizaciones de investigación, como SANS (Dave Shackleford, SANS Institute,
2014) y Netwrix (Netwrix Corporation, 2014) empresa especialista en soluciones
de auditoria, Donde se refleja un valor porcentual bajo de empresas que invierten
en herramientas SIEM para la gestión de registros. Una de las limitaciones son los
recursos económicos, ya que muchas de estas herramientas tienen un costo alto
como se visualiza en el Anexo A y el Anexo B, lo cual desestima el uso por parte
de las pequeñas y medianas empresas. Aunque en la actualidad ya hay
soluciones de no pago que ayudan con este proceso, también se encuentra una
limitante por el desconocimiento de las herramientas y aplicaciones tecnológicas
para el uso, análisis y aprovechamiento de los registros generados de los sistemas
de información y sus componentes.
De acuerdo a este escenario se pretende realizar una guía metodológica para la
gestión de registros que ayude a las empresas a generar un valor agregado de
seguridad a sus sistemas de información, aprovechando el análisis centralizado de
registros por medio de un SIEM de uso libre.
1.2.2 Pregunta de investigación
¿Cuáles son las fases para la gestión de registros mediante las herramientas
SIEM de uso libre?
12
1.3 JUSTIFICACIÓN
El tema de investigación se realiza con la siguiente finalidad:
Generar un valor agregado a nivel de seguridad, en la gestión y análisis de
registros de cada componente de infraestructura, que beneficia a organizaciones
que no cuentan con recursos o conocimientos suficientes para satisfacer
soluciones que permitan este objetivo1. (Shenk, 2015)
De acuerdo al planteamiento del problema y el desarrollo de la pregunta de
investigación, el proyecto contribuye a la concientización y motivación sobre la
seguridad de la información a través de la gestión y análisis de eventos de
seguridad, en empresas que consideran que proteger sus activos, no es
fundamental ni estratégico, porque el costo/beneficio de implementar soluciones
de seguridad es alto e innecesario. Adoptar de forma apropiada una gestión de
eventos de seguridad mediante un SIEM permite una mejor eficiencia operacional
y ahorrar costos a las empresas, ya que con todas las herramientas de seguridad
diseñadas para proteger de los diferentes vectores de ataque que constantemente
se encuentran originándose gracias al desarrollo tecnológico, el análisis de todos
los sistemas se vuelve administrativamente dependiente de recursos
especializados y procedimientos manuales, además el tiempo de reacción ante un
incidente es mucho mayor. La implantación de estos sistemas de gestión de
registros permite realizar un análisis más efectivo y eficiente, además de permitir
automatización de varias tareas reduciendo el uso de recursos, además del tiempo
de reacción y detección de ataques, reduciendo las pérdidas económicas de una
organización.
Aunque una solución SIEM no solo beneficia a las organizaciones a nivel de
seguridad y trazabilidad de sucesos, también contribuye a aquellas empresas u
organizaciones que pretenden implementar algunos controles como por ejemplo el
estándar PCI (Entidades financieras o que utilicen el comercio electrónico) o las
normas Sarbanes-Oxley (Organizaciones que cotizan en la bolsa de USA), dado
que estas exigen algunas características como automatización de los procesos de
auditoria, en donde los SIEM con el análisis y gestión de los eventos ayudan a
que el proceso sea más ágil al momento de extraer y solicitar la información.
1 Shenk, J. (25 de ABRIL de 2012). SANS INSTITUTE.
13
1.4 OBJETIVOS
1.4.1 Objetivo general
Proponer una guía metodológica para la gestión y análisis centralizado de registros de
seguridad a través de una herramienta SIEM.
1.4.2 Objetivos específicos
Seleccionar un modelo de mejores prácticas para la gestión centralizada de
logs.
Seleccionar herramienta SIEM de acuerdo a sus características para la
gestión centralizada de eventos de seguridad.
Proponer una guía metodológica de la gestión centralizada de registros con
base en recomendaciones del Instituto Nacional de Estándares y Tecnología y el
comparativo realizado.
Evaluar los pasos propuestos en esta guía mediante la definición e
implementación de un caso de prueba.
14
2. MARCOS DE REFERENCIA
En este capítulo se definieron los conceptos importantes que se requieren para
entender y comprender lo planteado en los siguientes capítulos.
2.1 MARCO CONCEPTUAL
Un (SIEM) Security Information and Event Management en inglés es una definición
utilizada para aplicaciones que involucran (SEM) Security Event Management
(Gestión de Eventos de seguridad) que recoge, agrega y actúa sobre los eventos
de seguridad y (SIM) Security Information Management (Gestión de Información de
Seguridad) que correlaciona, normaliza e informa sobre los datos de eventos de
seguridad recogidos. Las Herramientas SIEM ofrecen un análisis en tiempo real
para eventos de seguridad generados en gran medida por la infraestructura de los
sistemas de información. Por ejemplo:
Un log es un registro de datos que es originado de una grabación o captura de
eventos que ocurren dentro de los sistemas de información y redes de una
organización. Los registros se componen de entradas, cada entrada contiene
información relacionada con un evento específico que se ha producido dentro de
un sistema de información o red. Los registros dentro de una organización,
contienen eventos relacionados con la seguridad informática. Estos registros de
seguridad informática son generados por muchas fuentes, incluyendo software de
seguridad, antivirus, firewalls, sistemas de detección de intrusos, sistemas de
prevención de intrusos, sistemas operativos en servidores, estaciones de trabajo,
equipos de red y aplicaciones2. (Task, 2015)
El envío de mensajes de logs se realiza a través protocolos de red, cada uno de
los cuales tiene sus propios mecanismos y formatos definidos en que se envía los
logs, a continuación se presentan algunos de los utilizados para este envío3.
(Chuvakin, 2013)
Syslog: Es el más común de los mecanismos para recolección de logs, es un
protocolo cliente/servidor. Los mensajes de syslog se suelen enviar vía UDP, por
el puerto 514 en formato de texto plano.
2 Task, J. (25 de Abril de 2015). National Instituto of Standars and Tecnology. 3 CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER.
15
Aunque ya hay versiones que utilizan TCP para que los datos viajen cifrados
mediante SSL/TLS4. Para el envío de los registros de datos, la herramienta syslog
toma los registros de datos del Visor de Eventos (Windows) o de las notificaciones
que llegan al sistema operativo (Unix), para transmitirlos al servidor del SIEM.
(Chris, 2015)
SNMP: Protocolo Simpe de Administración de Red (por sus siglas en ingles
Simple Network Management Protocol) Es un protocolo para la transmisión de logs
de diversos tipos de datos generalmente utilizado para dispositivos de red. Se
dispone mediante un dispositivo que administra los equipos de la red y recibe las
notificaciones de los dispositivos administrados para reenviarlas al servidor
centralizado de logs.
Windows Event Log: Es un protocolo propietario de Microsoft para la
recolección y transmisión.
Bases de Datos: Es una manera estructurada para el almacenamiento y
recolección de logs. Donde se especifican los usuarios y privilegios que tendrán
sobre los registros de logs, esta base de datos es recomendable que no se
configure en el mismo tablespace de la base de datos de los registros, para evitar
vulnerabilidades de seguridad que se puedan presentar. Adicional se debe instalar
un programa para la lectura de los datos almacenados.
Una infraestructura de gestión de registros consiste en hardware, software,
protocolos de comunicación y medios utilizados para generar, transmitir,
almacenar, analizar y disponer de los datos contenidos en un registro. Entre las
infraestructuras de gestión se suelen realizar varias funciones que apoyan el
análisis y la seguridad de los datos de registro. Después de establecer una política
inicial de gestión centralizado de registros e identificación de roles y
responsabilidades, una organización debería desarrollar e implementar una o
varias infraestructuras de gestión que apoyen de manera efectiva la política y los
roles para la administración centralizada de registros de seguridad5. (Kent, 2015)
4 Chris, L. (24 de 10 de 2015). Cisco Systems The BSD Syslog Protocol. 5 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
16
Los SIEM tienen varias características y funciones principales, una de ellas es la
normalización, con la cual se busca obtener un almacenamiento particular y
consistente para todos los registros capturados, y los índices de estos registros,
permitiendo realizar una búsqueda rápida y clasificada. Esta característica permite
que las investigaciones forenses se realicen de una forma ágil y consistente. Se
debe tener en cuenta, que si el proceso para realizar la normalización es muy alto,
se incrementa considerablemente el consumo de los recursos del servidor de
aplicación del SIEM, por lo anterior se debe tener claro los datos que se van a
utilizar y realizar un estudio para evaluar si deben ser normalizados.
Las herramientas SIEM cada día buscan ser más útiles e importantes para las
organizaciones, tienen dos formas para su implementación, la primera es la
implementación sin el utilizar un agente en las maquinas que generan los
registros, de esta forma no es necesario instalar ningún software en las
herramientas que enviarán los registros al SIEM, este proceso genera que los
recursos del servidor SIEM sean muy altos, debido a que es ahí, donde se
realizaran los procesos de análisis, normalización y filtrado de los registros
capturados. La implementación con agente, instala un software en cada una de las
herramientas que enviarán registros al SIEM, los programas son los encargados
de realizar la normalización y filtrado, para luego enviarlos al servidor SIEM, el cual
realiza el proceso de análisis, correlación y monitoreo correspondiente.
2.2 MARCO TEÓRICO
2.2.1 Normatividad aplicable a la gestión de logs
La gestión de seguridad de la información federal (FISMA) , Hace énfasis en la
necesidad de que cada agencia federal desarrolle, documente e implemente un
programa para proporcionar seguridad de los sistemas de información de la
organización que apoyan sus operaciones y activos, NIST SP 800-53 creada en el
2005 hace énfasis en la creación de estos documentos con su más reciente
actualización lanzada el 30 de abril de 2013 y desarrollada por el Departamento de
Defensa, la Comunidad de Inteligencia, el Comité de Sistemas de Seguridad
Nacional, el Instituto Nacional de Estándares y Tecnología, esta actualización fue
motivada principalmente por la expansión de amenazas, debido a los crecientes
ataques cibernéticos sofisticados, la profesionalidad de los atacantes y la
frecuencia de los ataques.
17
Describe varios controles relacionados con la seguridad de aplicaciones,
confiabilidad, seguridad y capacidad de recuperación de los sistemas de
información, amenazas internas, seguridad de la cadena de suministro y la
administración de registros, incluyendo la generación, revisión, protección y
conservación de los registros de auditoría, así como las acciones que se tomarán
a causa de errores de auditoría6. (Joins, 2015)
Los registros también son útiles en las actividades de auditoría y análisis forense,
en el apoyo a investigaciones internas, establecimiento de líneas base y en la
identificación de tendencias operacionales y problemas de comportamiento de los
sistemas de información a largo plazo. Las organizaciones que almacenan y
analizan ciertos registros deben cumplir con la legislación y las regulaciones
federales. El Instituto Nacional de Estándares y Tecnologías (National Institute of
Standards and Technology) en su publicación especial (Special Publication 800-92
) de septiembre de 2006 emite el documento titulado Guía para Gestión de Logs
de Seguridad de la Información, documento que será tenido en cuenta para la
elaboración de este trabajo el cual aborda el manejo de registros, su
centralización y temas como la gestión de registro de seguridad informática, el
proceso de generación, transmisión, almacenamiento, análisis y disposición de los
datos de un registro de seguridad informática.
Un problema fundamental en la gestión de logs y que se presenta en las
organizaciones, es equilibrar de manera efectiva la infraestructura de gestión de
logs con el suministro continuo de datos, la generación registros y su
almacenamiento pueden ser temas complicados de gestionar por varios factores,
entre ellos un número alto de fuentes de donde son generados estos logs,
inconsistencia en los contenidos de los registros, formatos y marca de tiempo entre
las fuentes de datos y volúmenes grandes de registros. La gestión de logs también
implica proteger la confidencialidad, integridad y disponibilidad de la información7.
(Joins, 2015)
2.2.2 Características de los SIEM
Entre las infraestructuras de gestión encontramos el Security Information and
Event Management (SIEM) software que utiliza principalmente los formatos de
datos propietarios. Los productos SIEM tienen servidores centralizados que
6 Task, J. (25 de Abril de 2015). National Instituto of Standars and Tecnology. 7 Task, J. (25 de Abril de 2015). National Instituto of Standars and Tecnology.
18
realizan el análisis de registros, además de bases de datos para el
almacenamiento de estos8. (Karen, 2006)
Se debe tener en cuenta aquellas características que deben tener las
herramientas SIEM, y que ayudan con las funciones de almacenamiento, análisis y
eliminación de datos de logs, que no deben impactar de manera alguna los
recursos tecnológicos ni la integridad de los datos, para que las investigaciones
forenses basadas en los mismos no se vean afectadas. Entre estas características
se encuentran, la recolección de datos y la conversión de datos. La recolección de
datos, consiste en obtener los registros de datos mediante un software
denominado coleccionista (Collector) también conocido como agente, que se
encuentra instalado en las fuentes de logs, se describen como todo aquel
dispositivo, sistema operativo, aplicación o cualquier sistema de información que
generen registros de datos (logs)9. (Securosis, 2010)
La conversión de datos, es el proceso de analizar un registro en el formato fuente,
pero almacenarlo en la base de datos de la herramienta en un segundo formato,
para permitir la agrupación de eventos y la correlación de eventos entre otras para
una mayor efectividad de la herramienta, tango en reglas como en diagnóstico.
2.3 MARCO LEGAL
Actualmente no hay una regulación para la gestión de registros, se encuentra en
proceso de estudio la ISO/IEC 27044 — Information Technology — Security
Techniques — Guidelines for security information and event management.
Las plataformas SIEM ayudan al cumplimiento de muchas normas regulatorias
como PCI, SOX, HIPAA entre otras, pero la gestión centralizada de registros de
seguridad no hace parte esencial ni obligatoria para desarrollar y apoyar estas
regulaciones.
8 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 9 Securosis. (25 de 8 de 2010). Securosis.
19
3. METODOLOGÍA
Para este capítulo se trabajara en la definición de la descripción de las
características utilizadas para el desarrollo de este trabajo de grado.
3.1 FASES DEL TRABAJO DE GRADO
En el proceso de desarrollo del presente proyecto de investigación y en el logro de
los objetivos propuestos del mismo, se desarrolla en tres etapas, la fase de
planeación donde se desarrolla la propuesta y el anteproyecto, los cuales siendo
aprobados, dan inicio a la fase de ejecución donde se desarrollarán las tareas para
el cumplimiento de los objetivos propuestos. La fase final es de verificación donde
se evaluaran y realizaran ajustes o correcciones que las tareas requieran.
3.2 INSTRUMENTOS O HERRAMIENTAS UTILIZADAS
Para el logro de los objetivos planteados de este proyecto de investigación y
teniendo en cuenta lo anteriormente descrito en el enfoque y el tipo de
investigación, las técnicas e instrumentos que se utilizan en este proyecto de
investigación, son un análisis comparativo y documental, dado que se trabaja a
partir de los datos que surgen de la indagación de diferentes herramientas SIEM y
observación en el proceso de la implementación del caso de prueba, para lograr el
cumplimiento del objetivo general.
3.3 ENFOQUE
El enfoque de esta investigación es de carácter cualitativo, toda vez que se basa
en las características y descripciones ya definidas para las soluciones SIEM de
uso libre, y en un proceso de observancia en la implementación de un SIEM,
proponiendo una guía metodológica que ayude en este proceso a las
organizaciones.
3.4 TIPO DE INVESTIGACIÓN
Esta investigación es comparativa y proyectiva. Comparativa en cuanto se
expondrán las características y descripciones de diferentes herramientas SIEM de
uso libre y proyectiva, ya que una vez que se analicen las diferentes
características de estas herramientas se propondrá una guía metodológica que
20
ayude a su entendimiento y funcionalidad con el proceso de implementación en un
caso de prueba.
21
4. SELECCIÓN MODELO DE MEJORES PRACTICAS DE GESTIÓN DE LOGS
En este capítulo se revisa varios documentos de investigación de mejores
prácticas para la gestión de logs, escogiendo uno para revisar las características
esenciales que permita la selección adecuada de la herramienta SIEM, finalizando
el capítulo se presenta un modelo de acuerdo a la documentación analizada.
De acuerdo a la investigación se analizan varios documentos de investigación de
empresas u organizaciones dedicadas a temas de seguridad de la información,
como lo son Arcsight, EMC – RSA Envision, IPswitch, alert logic, una de las áreas
a revisar es la gestión de registros de datos (logs).
Best Practices. Event Log Management for security and Compliance Initiatives,
este documento relaciona los requisitos necesarios para las herramientas ELM
(Gestión de Registro de Eventos) y las mejores prácticas para disminuir el
potencial de violaciones de seguridad y reducir la posibilidad de problemas legales
o de cumplimiento en las organizaciones10. (Ipswitch, 2015)
Log Management Best Practices. The Benefits of Automated Log Management, en
el documento se recomienda recoger, consolidar y procesar cualquier dato o
registro generado en la organización, para ayuda de investigaciones y trazabilidad
de eventos11. (Alertlogic, 2015)
Log Management Best Practices. The Foundation fo Comprehensive Security
Information and Event Management, este documento enseña mejores prácticas en
gestión de registros que deben basarse en los requisitos de la normativa aplicable
y a la orientación de un asesor legal, empresarial, objetivos operativos y análisis
de riesgos. Aunque concluye que las mejores prácticas deberían ser desarrolladas
por cada organización12. (Envision, 2007)
Succesful SIEM and Log Management Strategies for Audit and Compliance. Este
documento plantea una guía, definiendo y separando los eventos de interés,
documentando el alcance de cada uno y el proceso a realizar13. (Swift, 2015)
ArcSight Logger – Poniendo en valor la información de los logs corporativos. Este
documento sugiere mejores prácticas enfocándose en 4 objetivos específicos,
10 Ipswitch. (9 de 5 de 2015). Ipswitch . 11 Alertlogic. (10 de 5 de 2015). Alertlogic. 12 Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision . 13 Swift, D. (3 de 5 de 2015). SANS Institute.
22
Cumplimientos de Acuerdos de Servicio, cumplimiento de normativas legales,
disminución de tiempos en incidencias de seguridad y mayor visibilidad de las
amenazas14. (Arcsigth. 2015)
En los documentos de investigación hay concordancia en las características y
buenas prácticas generales que ayudan y son soporte para una adecuada gestión
centralizada de logs y su influencia en la seguridad de la información.
Se selecciona como base para definir las características de la herramienta SIEM,
el modelo de buenas prácticas presentado en el documento de RSA Envision
apoyado con el documento de investigación del instituto SANS de David Swift.
RSA Envision, es una división de la empresa EMC encargada de investigación y
producción de soluciones de seguridad. Las mejores prácticas para una efectiva
administración de logs se centran en cinco objetivos principales15. (Envision, 2007)
Tecnología, procedimientos y políticas para el registro de logs.
Captura y generación de logs.
Almacenamiento y retención de logs.
Análisis de logs. Seguridad y protección de logs.
En caso de que cualquier organización cumpla con los 5 objetivos para la gestión
de logs de manera correcta se puede generar un valor en los siguientes aspectos
definidos en el documento de investigación Log Management Best Practices; The
Foundation of Comprehensive Security Information and Event Management16:
(Envision, 2007)
Cumplimiento. Algunas normas regulatorias como HIPAA, PCI, SOX, FISMA
entre otras, tienen condiciones especiales para la retención y recolección de logs,
pueden evitar problemas de no cumplimiento y por lo tanto costos y sanciones,
además reduce costos en auditorias de cumplimiento de estas normas, al reducir
el tiempo en el análisis de logs mediante el mantenimiento de la integridad de los
logs y reportes que facilitan el trabajo de los auditores.
Gestión de riesgo. Mediante el monitoreo en tiempo real se puede
evidenciar y prevenir riesgos de seguridad, evitando costos por riesgos de
reputación, legales y relación con clientes
14 Arcsigth. (10 de 5 de 2015). Arcsigth. 15 Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision. 16 Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision.
23
Asuntos legales. Mediante la gestión eficiente de logs, se consigue
evidencia valida que ayuda a resolver asuntos legales, sea internos o externos, o
en asuntos jurídicos por delitos informáticos.
Forense. En caso de incidentes de seguridad de la información, tener
acceso a registros y el análisis de estos, permite realizar una investigación rápida y
fiable, ayudando a detectar fallas de seguridad para mitigar estas brechas de
seguridad y evitar costos en su remediación y detectando la fuente que origino el
incidente.
Almacenamiento. Mejora la relación costo/beneficio del servicio de
almacenamiento de una organización mediante políticas, procedimientos y análisis
en el proceso de gestión de logs, para almacenar solo los registros de datos
apropiados y relevantes para la administración, además puede apoyar el tema de
clasificación de la información en políticas de respaldo.
Operación. El análisis efectivo de logs reduce tiempos de operación y
recurso humano que estos necesitan, el análisis de monitoreo reduce en procesos
para subir los sistemas de información y es eficiente contra amenazas evidencian
en menor tiempo en resolución de problemas de infraestructura.
4.1 TECNOLOGÍA, PROCEDIMIENTOS Y POLÍTICAS PARA EL REGISTRO DEL LOG
Este objetivo se puede desarrollar estableciendo políticas y procedimientos que
son respaldados por la organización, que definen el alcance, los recursos y los
objetivos para la gestión de logs, estas deben estar alineadas con políticas de la
organización.
Se recomienda establecer procedimientos operacionales para configuración de las
fuentes generadoras de logs, análisis de logs, identificación de eventos y
administración de almacenamiento.
Se deben definir roles y responsabilidades para el proceso de gestión de logs,
además de contar con entrenamiento de las personas que se involucren y debe
especificarse la documentación y herramientas que deben utilizar.
Debería incluirse una plataforma dedicada y centralizada para la administración de
logs y el almacenamiento de los mismos, que tenga una ubicación física apropiada
y segura, además de tener disponibilidad de acceso para los involucrados, que
24
pueda automatizar el análisis de los logs almacenados, de manera confiable y
consistente además de incluir controles de seguridad para evitar su modificación o
acceso no autorizado a los datos.
La plataforma debería tener facilidad para su uso, monitoreo y análisis, además de
incluir escalabilidad y definir la capacidad de los recursos necesarios, de acuerdo
a la necesidad de negocio de cada organización17. (Envision, 2007)
4.2 CAPTURA Y GENERACIÓN DE LOGS
Para cumplir este objetivo de manera exitosa, deben ser recogidos los registros de
datos necesarios para el cumplimiento de las regulaciones que se encuentra
expuesta una organización. Se debe recoger los logs de interés para realizar la
revisión, análisis, examen y reconstrucción de los datos mediante el historial de
sus registros, además de ser una herramienta para investigación de incidentes.
Los logs generados deben ser de sistemas operativos, dispositivos de seguridad,
almacenamiento y aplicaciones, se debe diseñar la infraestructura de gestión de
logs de manera que sea escalable, con un volumen alto de registro de datos y se
deben capturar todos los logs de los sistemas críticos, no es recomendable filtrar
los registros de datos desde las fuentes generadoras de logs, después el sistema
de gestión debe ser capaz de hacer su filtro de manera inteligente.
Es recomendable habilitar el registro de datos de auditoria en los sistemas, dispositivos y
aplicaciones que sean críticos para la organización y los cuales deberían participar en la
gestión de logs, tener configurado de manera apropiada, permite que la auditoria de estos
sistemas genere las alarmas correspondientes. Los logs también deben ser capturados
para identificar campos específicos requeridos por normas regulatorias, por ejemplo
identificación de usuario, marco de tiempo, información de red y la etiqueta del nivel
impacto de un evento18.(Envision, 2007)
Los tipos de logs que deben ser capturados y tratados son:
Accesos de usuario.
Acceso privilegiado o administrativo.
Uso de mecanismos de autenticación e identificación.
Accesos remotos e inalámbricos
17 Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision. 18 Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision.
25
Cambios en los sistemas o configuración de aplicaciones.
Cambios de privilegios de acceso.
Uso de utilidades del sistema.
Activación o desactivación de sistemas de seguridad.
Accesos a registros de auditoria.
Los registros de datos generados y obtenidos por el sistema de gestión de logs,
debe ser capaz de realizar trazabilidad a través de usuarios únicos e individuales.
La sincronización del tiempo en la generación de logs de las fuentes es de vital
importancia ya que influye en la confianza del análisis de los mismos, por tal
motivo se recomienda utilizar un servidor NTP (Network Time Protocol, protocolo
de red para sincronizar los relojes de los sistemas informático), para sincronizar el
tiempo de los sistemas involucrados en la gestión de logs19. (Envision, 2007)
Se debe tener en cuenta asegurar el proceso de transmisión de la información
sensible a través del sistema de gestión centralizada de registros, al igual que en
su almacenamiento, se debe garantizar controles para acceder a la información y
no permitir acceso no autorizado a estos eventos20. (Envis, 2007)
4.3 ALMACENAMIENTO Y RETENCIÓN DE LOGS
Se considera determinar los requerimientos de retención y almacenamiento en tres
etapas diferentes.
Datos de producción. Son datos usados activamente para el análisis y
revisión en tiempo real, evaluación y auditorias periódicas.
Datos de respaldo. Son los datos que son una copia exacta de los datos de
producción, son usados si los datos en producción son comprometidos o
corruptos.
Datos de Archivo Activo. Son una parte de los datos de producción que son
almacenados en un tiempo mayor por cuestiones regulatorias, requerimientos
legales o forenses.
Después se debe considerar como será almacenada la información, de acuerdo a
las etapas previamente establecidas.
19 EMC-RSA Envision. 20 Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision.
26
Almacenamiento online. Los datos son almacenados en redes de alto
rendimiento para que el acceso sea rápido y ofrezca disponibilidad a un alto
número de usuarios.
Almacenamiento Near-line. Los datos son almacenados en sistemas
removibles que sean disponibles para pocos usuarios dedicados por largos
periodos de tiempo.
Almacenamiento Off-line. Los datos son alojados en discos o cintas y deben
mantenerse en algún tipo de librería garantizando el acceso después de
montados21. (Envis, 2007)
Para definir los tiempos de retención y mecanismos de almacenamiento se
deberían desarrollar las siguientes preguntas:
¿Porque los logs son necesarios?
¿Cuándo se debe tener acceso a los logs?
¿Cuánto tiempo se tiene que devolver?
¿Cómo necesitan ser accedidos?
Se recomienda retener los logs en una infraestructura de almacenamiento segura
y bien administrada, una clave para la fácil administración es la centralización en
una plataforma, debido a que facilita acceder de manera controlada a los registros
de datos. Para tener una auditoria confiable se debe proveer acceso basado en
roles a los logs almacenados, además de proveer controles de acceso.
La información que debe ser consultada frecuentemente debe estar disponible
todo el tiempo a través de un almacenamiento online, Se aconseja que los datos
de producción debería tener una retención de al menos 15 meses, para asegurar
evidencia en incidentes, generar una reacción rápida en caso de que se
comprometa algún sistema de información, disminuyendo el impacto al negocio.
El tiempo de retención también asegura tener acceso cuando se presenten
auditorías internas o externas, normalmente tienen un periodo anual de acuerdo a
su ciclo de vida, asimismo algunas normas regulatorias también definen estos
tiempos de retención.
La retención en los datos de backup, debe garantizarse en el mismo periodo que
los de producción. En el caso de los datos para archivado, deben estar alineados a
los marcos regulatorios a los que se encuentre sometido la organización,
21 EMC-RSA Envision.
27
obligando a retenerlos generalmente en un periodo mayor a 5 años, sus objetivos
son de tipo legal, para casos de investigación además de registros para control y
auditoria del negocio de cada organización.
Se recomienda asegurar estos procesos mediante políticas, para evidencia digital
y por procedimientos legales, los logs deben ser almacenados con el mismo
formato original de los archivos de log de los activos generadores de estos. Otro
punto a considerar es los procedimientos, políticas y métodos para el retiro y la
eliminación de los datos22. (Envis, 2007)
4.4 ANÁLISIS DE LOGS
En esta etapa de la gestión centralizada de los logs, es necesario revisar y hacer
análisis frecuentemente para ayudar a identificar eventos o registros anómalos.
Los logs deberían ser revisados regularmente en tiempo real y mostrar históricos
al menos de un día, un mes y tres meses.
Es importante que los registros de datos puedan ser acumulados, que precisa de
identificar un mismo tipo de log y este ser almacenado con la cantidad de registros
repetidos, esto facilita y hace más confiable el análisis de los mismos. Automatizar
el proceso de análisis de logs permite mejorarlo significativamente, ya que reduce
tiempos e ineficiencia si el método de análisis es manual, generando un impacto
grande en caso de algún incidente, esto se representa en costos, por lo cual es un
punto importante que da valor a la gestión.
Aumentar la productividad, eficiencia y confiabilidad en el análisis de logs, es
necesario mediante el uso de herramientas de correlación, que es el análisis de
múltiples fuentes que estén involucrados en un incidente para reducir falsos
positivos, confirmar y tener evidencia de un incidente de forma fiable.
La utilización de reportes ayuda a incrementar la rapidez y eficacia en el análisis
de logs, estos tienen indicadores históricos que pueden ayudar a evidenciar
comportamientos y dar significado a la información de acuerdo a los propósitos de
seguridad.
Otra recomendación es tener disponible un sistema de alertas que puedan
comunicar el estado de un evento y clasificar su prioridad, así como desarrollar
22 Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision.
28
líneas base para definir tipos de logs de interés que puedan analizar de manera
más apropiada23. (Envision, 2007)
4.5 SEGURIDAD Y PROTECCIÓN DE LOGS
La premisa de este punto es asegurar la disponibilidad, confidencialidad e
integridad de los logs a través de todo su ciclo de vida desde su generación,
tratamiento, almacenamiento, retención y eliminación. Los logs son susceptibles a
su alteración o eliminación, si no tienen los controles de seguridad durante su
almacenamiento y en su transmisión.
La manipulación de estos registros puede tener un impacto crítico para el negocio
de cualquier organización, como ocultar un incidente o evidencia del mismo, robo
de información, suplantación entre otros delitos informáticos.
Se debería tener procesos y procedimientos seguros sobre los activos o sistemas
que generan los logs, mediante control de accesos, roles y responsabilidades bien
definidos, políticas y procedimientos sobre control de cambios.
Es recomendable tener mecanismos seguros para evitar fuga o robo sobre los
medios de transporte de la información como protocolos de cifrado, además de
mecanismos que aseguren la disponibilidad e integridad de los datos, como
algoritmos criptográficos y firmas digitales.
Es importante definir medios de protección de los archivos de logs donde se
encuentran almacenados ya sea mediante controles físicos y lógicos de acceso,
definir una capacidad adecuada de recursos para almacenamiento y que se haga
uso de medios de almacenamiento que no puedan ser modificados, garantizando
la integridad de los logs. Se recomienda la protección de los sistemas de
almacenamiento mediante análisis y controles contra riesgos ambientales. Además
se debe considerar como parte fundamental el desarrollo de procesos de continuidad de
negocio24. (Envision, 2007)
23 Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision. 24 EMC-RSA Envision.
29
4.6 MODELO BUENAS PRACTICAS GESTIÓN DE LOGS
De acuerdo a las buenas prácticas definidas en el paper de investigación de EMC
– RSA, Se define el siguiente modelo para la gestión de logs, compuesto por las
siguientes actividades.
El modelo generado de acuerdo al análisis de los trabajos de investigación sobre
buenas prácticas para la gestión de logs, se encuentra dividida en dos
subprocesos uno realizado por los activos fuentes de registros de datos y eventos
de seguridad, El comienzo del evento es la generación de registros de datos
(logs), luego deben ser transmitidos a la infraestructura del proceso de gestión de
logs, la cual está conformada por servidores y aplicaciones para el tratamiento de
los registros, en el presente caso es una plataforma SIEM.
El SIEM debe tratar los logs al recibirlos y ejecutar actividades de almacenamiento
y retención, análisis, aseguramiento de logs. Si los registros son de interés o
tienen una influencia e impacto para el negocio debe ser almacenado en caso
contrario deben filtrarse y ser ignorados. La eliminación de los registros que son
almacenados, deben realizarse luego de cumplir con los tiempos de retención
evitando emplear recursos en registros no válidos para incidentes e
investigaciones.
El análisis de logs puede ejecutar la normalización, correlación o reportes, todas
actividades válidas para el análisis y el resultado son alertas y notificaciones de
eventos de seguridad que tienen algún impacto en la infraestructura de la
organización después de la identificación de algún incidente de seguridad se debe
ejecutar planes de remediación, manteniendo así el cumplimiento de políticas y
normas regulatorias con respecto a la seguridad de la información.
30
Figura1. Modelo de Gestión de Logs
Fuente: Autor
31
5. SELECCIÓN DE HERRAMIENTA SIEM LIBRE
En este capítulo se describen cinco herramientas SIEM de uso libre y se realiza un
comparativo de las características que se determinaron anteriormente para el
cumplimento del primer objetivo.
5.1 DESCRIPCIÓN DE HERRAMIENTAS SIEM
Con base al modelo planteado y desarrollado en el capítulo anterior, se investigan,
evalúan e identifican cinco herramientas SIEM de uso libre, las cuales cuentan con
características esenciales que se utilizan en la gestión centralizada de registros de
seguridad, con el objetivo de seleccionar la herramienta que se adecue a los
requerimientos del proyecto y al modelo planteado de acuerdo a un análisis
objetivo y una comparación de sus fortalezas, debilidades, características de uso,
experiencia en el mercado, facilidad y documentación entre otros factores.
A continuación se especifican y describen cada una de las herramientas SIEM y
sus características:
5.1.1 Prelude SIEM
Las características de Prelude SIEM son recoger, almacenar, normalizar, clasificar,
agregar, correlacionar y generar reportes de eventos relacionados con seguridad.
La aplicación no utiliza agentes en los dispositivos de donde obtiene los logs.
Provee un sistema centralizado para realizar análisis los eventos de varios
sistemas de información, mediante la generación de reportes de seguridad
entendibles y útiles para su análisis.
Prelude SIEM dispone de 3 versiones:
Prelude OSS
Prelude PRO
Prelude Enterprise
Se enfoca en la versión OSS ya que es la versión libre de Prelude bajo la licencia
GPL V2, la diferencia entre esta y las dos versiones de pago, se encuentra en que
manejan módulos y herramientas más avanzadas, OSS ofrece funciones de
alertas con funciones limitadas y un rendimiento inferior, además se encuentra
32
diseñada para infraestructuras pequeñas, sistemas no críticos y para
investigaciones académicas.
Prelude SIEM se encuentra diseñado en lenguajes de programación C y C++ y se
encuentra disponible para instalar en distribuciones Linux. Prelude OSS se
encuentra compuesto por los siguientes módulos.
Libprelude. Librería de comunicación entre los módulos.
Libpreludedb. Librería de acceso a base de datos (No optimizada).
Prelude Manager. Almacenamiento y recolección de eventos (Limitado).
Prelude Correlator. Módulo de correlación de eventos.
Prelude LML. Administrador de archivos de logs.
Prewikka. Interfaz gráfica donde se muestran los eventos.
En Prelude SIEM se destacan las siguientes características:
¿Porque los logs son necesarios?
Gestionar amenazas internas y externas en tiempo real.
Obtener, analizar y preparar reportes de estado.
Analizar datos específicos de eventos de seguridad.
Apoyar en el cumplimiento regulatorio de leyes en el tema de seguridad.
Prevenir daños o fallas en los datos y recursos de una organización.
Asegurar la compatibilidad con políticas de seguridad internas y externas.
Informar sobre amenazas potenciales y eventos sospechosos en la red.
Establecer los enlaces entre la información, eventos y sus consecuencias.
Identificar áreas de ineficiencia y lentitud y determinar sus causas.
Monitorear la actividad de red y gestión de riesgo de una manera optimizada
Mostrar evidencia de buenas prácticas durante auditorias25. (Prelude, 2015)
25 PRELUDE. (16 de 8 de 2015).
33
5.1.2 OSSEC
Es una herramienta de uso libre (open source, en inglés) potente, que realiza detección de
intrusos basados en host, análisis de logs, validación de integridad de archivos, monitoreo
de políticas, detección de rootkit, alertas y respuesta activa en tiempo real. Tiene respaldo
y soporte de una empresa líder de seguridad como lo es TRENDMICRO. OSSEC Ayuda a
las empresas a alcanzar los requerimientos de cumplimiento en normas como PCI,
HIPAA, SOX entre otros. Permite detectar cambios o amenazas que puedan sugerir el
incumplimiento en temas de seguridad de la regulación o normas a las que se encuentra
sujeta la organización.
OSSEC permite su instalación en múltiples plataformas basadas en Unix,
Windows, Mac y Vmware ESX. OSSEC permite configurar alertas de incidentes
por plataforma, enfocando el nivel de prioridad y criticidad de los incidentes. La
integración con los protocolos smtp, sms y syslog permite el envío de alertas en
tiempo real a través de correo o dispositivos móviles como smartphones, Además
tiene opciones para activar una respuesta inmediata como bloqueo, cuando se
evidencia un evento de alto impacto.
OSSEC se integra con la mayoría de plataformas para reporte centralizado y
correlación de eventos como la mayoría de productos SIEM. OSSEC provee una
gestión centralizada y simplificada para administrar las políticas sobre múltiples
sistemas operativos y también permite el ajuste granular sobre estas políticas.
OSSEC es flexible en su modo de funcionamiento porque tiene opciones como
monitoreo con agente o sin agente, en dispositivos de red y servidores.
Entre sus características más importantes se encuentran:
Verificación integridad de archivos.
Monitoreo de logs en tiempo real.
Detección de Rootkits.
Respuesta activa a incidentes26. (OSSEC, 2015)
26 OSSEC. (16 de 8 de 2015). OSSEC.
34
5.1.3 OSSIM
Son las siglas de Open Source Security Information Management en inglés, es un SIEM
creado por AlienVault. Es una herramienta muy completa para recopilación, normalización
y correlación de eventos de seguridad. Su principal objetivo es proporcionar un
herramienta SIEM de uso libre, debido a la falta de productos de código abierto
disponibles en el mercado, Desde su creación, cuenta con colaboración de profesionales
en el campo de la seguridad que la han utilizado y ajustado de acuerdo a las necesidades
de las organizaciones, por lo tanto OSSIM tiene la experiencia y ajustes en su desarrollo
para brindar una herramienta robusta y de fácil administración para las organizaciones en
las actividades de recolección, normalización, análisis, correlación y gestión centralizada
de logs.
OSSIM es una plataforma unificada con muchas de las funciones de seguridad
esenciales como:
Descubrimiento de activos.
Evaluación de la vulnerabilidad.
Detección de intrusiones.
Monitoreo del comportamiento.
SIEM.
OSSIM aprovecha la experiencia de AlienVault, permitiendo a los usuarios
contribuir y recibir información en tiempo real sobre los hosts maliciosos. Además,
ofrece un desarrollo frecuente y actualizado de la herramienta. OSSIM ofrece la
oportunidad de incrementar la visibilidad y el control de la seguridad en la red27.
(ALIENVAULT, 2015)
5.1.4 GRAYLOG.
Graylog es un SIEM de código abierto totalmente integrado para la recolección,
indexación y el análisis de datos estructurados y no estructurados de cualquier fuente.
Entre sus características más importantes se encuentran.
No requiere una inversión económica en software, debido a que es de uso libre.
Plataforma que permite mejorar tiempos de respuesta para gestionar los
registros de datos.
27 ALIENVAULT, O. . (17 de 8 de 2015). OSSIM - ALIENVAULT.
35
Plataforma centralizada para la gestión de logs.
La arquitectura permite mejoras de procesamiento y almacenamiento de la herramienta, cambiando o incrementando los recursos de la misma.
Formato de mensaje de registro optimizado (GELF, en inglés) mejora la eficiencia de procesamiento de los mensajes.
La arquitectura de la herramienta, permite el procesamiento en tiempo real de logs antes de su almacenamiento.
Utiliza API REST, son sistemas para que desarrolladores puedan integrar otro software de gestión.
Graylog motiva la adopción de este tipo de herramientas y contribuye a acelerar el
desarrollo para la seguridad de la información28. (Graylog, 2015)
5.1.5 LOGALYZE
LOGalyze fue diseñado para cumplir con los requisitos principales de una gestión
centralizada de registros, se incluyen dentro de sus características.
La capacidad de recolectar cualquier tipo de logs de cualquier fuente, con o sin necesidad de instalar un agente, en los dispositivos generadores de logs.
Normalizar los logs para la presentación de informes y tener un análisis más eficaz.
Buscar en todos los datos recogidos desde aplicaciones compatibles y personalizadas.
Proporcionar informes para su análisis.
Proporciona trazabilidad para auditorías internas permitiendo a las organizaciones
observar los registros. Como acciones de usuario y cambios de configuración.
Estos eventos pueden ser analizados y reportados.
LOGalyze tiene diferentes fuentes compatibles para la administración de logs,
como los sistemas operativos Windows, Linux, Unix, Dispositivos de red y
aplicaciones29. (Logalyze, 2015)
28 Graylog. (7 de 8 de 2015). Graylog.
29 Ltda., L. Z. (17 de 8 de 2015). LOGALYZE Zuriel Ltda
36
5.2 COMPARATIVO HERRAMIENTAS SIEM
Se compararon las distintas herramientas de acuerdo a las características y
funcionalidades enfocadas a la gestión de logs, que cada una ofrece, a
continuación se relaciona la tabla con el comparativo realizado.
Cuadro1. Comparativo Herramienta SIEM
HERRAMIENTAS
PRELUDE OPENSOUR
CE OSSEC OSSIM GRAYLOG LOGALYZE
CARACTERISTICAS
Descubrimiento de Activos
X
Gestión Centralizada
X X X X X
Recolección de Logs y eventos de seguridad
X X X X X
Correlación de Eventos
X X X X
Análisis de Logs
X X X X X
Clasificación y Prioridad de eventos
X X X X
Monitoreo en tiempo Real
X X X X X
Normalización
X X X X X
Reportes X X X X X
Interfaz Gráfica de administración
X X X X X
Modo de recolección de Eventos
Agente/Sin Agente
Agente/Sin Agente
Agente/Sin Agente
Agente Agente/Sin
Agente
S.O. SOPORTADO
LINUX/UNIX X X X X X
MAC X X
BSD X X X
37
WINDOWS X X X X
Fuente: Autor
5.3 SELECCIÓN HERRAMIENTA SIEM
Después del análisis realizado de las herramientas SIEM para la gestión de logs
de seguridad, se decide por la herramienta OSSIM de AlienVault, ya que cuenta
con la mayor cantidad de características para una herramienta SIEM Open Source,
además de tener el soporte de una empresa especializada ya por algunos años en
el ámbito internacional, como lo es Alienvault, que a pesar de su herramienta
SIEM de pago, Ofrece una robusta plataforma en su versión Open Source.
Entre las características relevantes se encuentra la correlación de registros, la
gestión de incidentes y la integración de varias herramientas como SNARE,
OSSEC, SNORT, OPENVAS, NAGIOS, ARPWATCH que le permiten ser una
herramienta muy flexible y robusta para la gestión centralizada de eventos de
seguridad.
38
6. ESTRUCTURA DE LA GUÍA METODOLÓGICA
En esta sección se detalla recomendaciones generales operativas y técnicas,
respecto a las actividades para desarrollar e implementar la gestión de registros de
datos (logs) manera eficiente, apoyados en estándar NIST SP800-92 y las
consideraciones evaluadas en el documento.
6.1 GUÍA METODOLÓGICA
De acuerdo a la investigación y al soporte de algunos estándares y organizaciones
de investigación como la NIST, la guía se divide en las siguientes actividades para
lograr que la gestión de logs se encuentre dentro de un marco fundamental para la
seguridad de la información de la organización. Las actividades aquí propuestas
son implementadas o desarrolladas dependiendo de la necesidad y actividad de la
organización.
Definición de alcance: Definir que plataformas y tipos de logs que harán parte del proceso de gestión.
Políticas y Procedimientos: Generación de Políticas y Procedimientos que puedan formalizar e implementar el proceso de gestión de logs.
Infraestructura para la Gestión de logs: Cada organización de acuerdo a sus necesidades, debe adecuar una infraestructura para la gestión de Logs.
Generación y Transmisión: Asegura que los registros de logs de las plataformas definidas en el alcance sean generados y transmitidos a la plataforma de gestión de logs.
Retención y Almacenamiento: Definir requerimientos y políticas para retención y almacenamiento de logs.
Análisis Automático y Correlación: Implementar y ajustar mecanismos automáticos para el análisis y correlación de logs.
Seguridad de los registro de logs: Implementar mecanismos de seguridad para protección de logs en las actividades de recolección, transmisión, almacenamiento y retención.
Notificación de alertas: Establecer y configurar medios de notificación de alertas
39
Análisis de reportes: Configurar y ajustar reportes estadísticos e históricos para validación de comportamientos de la infraestructura tecnológica.
Mitigación de incidentes: Establecer procedimientos gestión de incidentes para mitigar las amenazas identificadas y reportadas mediante la gestión de logs.
Eliminación de logs: Aplicar procedimientos y políticas para la eliminación apropiada de logs.
A continuación se describen en detalle cada una de las actividades.
6.1.1 Definición del alcance
En esta etapa se debe definir los componentes que son involucrados en la gestión de
logs.
La definición del alcance es fundamental en el proceso de gestión de los registros de datos, debido a que la ausencia, omisión o adición de alguna fuente de logs que pueda impactar los servicios o procesos de la organización, mantiene un riesgo alto que se materialice un incidente debido a que no hay un monitoreo de los mismos, además de no conseguir una respuesta reactiva efectiva y rápida
6.1.1.1 Dispositivos de hardware o software. Se recomienda identificar los activos ya sea software o hardware que tengan más criticidad para el negocio, algunas de las herramientas que ayudan a realizar esto es mediante reuniones y entrevistas con los responsables de los activos, metodologías para valorar riesgos e impactos, además del inventario de activos. En el anexo C, se detallan algunos de los dispositivos de hardware. Cabe señalar que cada organización tiene su propia infraestructura de TI y la importancia de sus activos dependen de sus necesidades de negocio30. (CHUVAKIN, 2013)
6.1.1.2 Responsables en el proceso de gestión de logs. Definir las responsabilidades dentro del proceso de gestión de logs, para que la gestión sea adecuada, se identifiquen las actividades de cada rol con respecto a los logs y definir las personas que se encuentran involucradas en el proceso31(Kent, 2006). El anexo D establece un ejemplo de los roles involucrados en el proceso de gestión de logs.
30 CHUVAKIN, D. A., & SCHMIDT, K. J. 31 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
40
6.1.1.3 Tipos de logs. Los sistemas de información generan varios tipos de registros de datos (logs), algunos son eventos no relevantes, por lo tanto es necesario realizar un filtro de los logs que generan más impacto para cada uno de los sistemas de información, la responsabilidad de definir los registros que serán tratados en el proceso de gestión de logs es el dueño de cada activo, debido a que identifica que registros de datos sugieren un
monitoreo y análisis dado que es la persona que mejor conoce el sistema de
información32(CHUVAKIN, 2013). En el anexo E se mencionan las categorías y tipos de logs que las fuentes pueden generar, muy útil para su filtro.
6.1.1.4 Infraestructura para la gestión logs. En el alcance se debe definir con que
infraestructura se va a contar para implementar la gestión de registros de datos (logs), Se debe realizar una caracterización en el diseño y la implementación de la infraestructura para la gestión de logs de acuerdo al alcance, tiempos de retención, dispositivos tecnológicos (SIEM, Servidor SYSLOG), forma de almacenamiento, controles de seguridad, forma de transmisión, capacidad de los recursos como procesamiento, memoria y ancho de banda, además de los recursos físicos y humanos para su gestión.
6.1.2 Crear una política y procedimientos para la gestión de Logs
La política debe ser clara y concisa con los requerimientos y recomendaciones
para la gestión de logs, debe estar enfocada y alineada a la misión y visión de
cada organización, Se debe tener definido de acuerdo a las necesidades de
negocio y cumplimiento a las normas regulatorias que aplique, En el anexo F Se
da un ejemplo de una política de gestión de acceso siguiendo las
recomendaciones expuestas.
Los procedimientos fundamentan y apoyan la política de gestión de logs a nivel
operativo, estos detallan la operación, soporte y monitoreo del proceso, al igual
que se debe ser claro y efectivo en la comunicación de la política y
procedimientos, además se debe especificar las actividades y responsabilidades
dentro del proceso de la gestión de logs.
6.1.2.1 Se deben establecer los requerimientos en caso de que aplique a la
organización referente a33:
32 CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER. 33 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
41
Generación de logs.
Transmisión de logs.
Almacenamiento de logs.
Disposición de los logs.
Análisis de logs.
Seguridad de los logs. (Kent, 2006)
6.1.2.2 Establecer políticas que se puedan cumplir. Que no amenace con la
interrupción o disponibilidad de los procesos estratégicos o de negocio de
una organización. Definir un alcance correcto. Sin ambigüedad evitando
ausencia de responsabilidad o falta de compromiso con el proceso de
gestión de logs34. (Kent, 2006)
6.1.2.3 La política debe ser revisada periódicamente. Cada vez que hayan
cambios en la infraestructura de tecnología, en caso de necesitar
actualización debe ser generada para mantener el proceso alineado con
los propósitos de la organización.
6.1.2.4 Especificar los eventos más significativos para su tratamiento y análisis.
6.1.2.5 Hacer referencia a normas y regulaciones. Que se encuentren
relacionadas dentro de la gestión de logs y deban ser aplicadas de
acuerdo al negocio de una organización35. (Kent, 2006)
6.1.3 Infraestructura gestión de Logs.
La presente guía sugiere el uso de una herramienta SIEM de uso libre como dispositivo
central para la gestión de logs, la herramienta es un software el cual debe ser instalado en
una máquina que garantice los recursos evaluados en la definición del alcance, además
estimar crecimiento en el futuro de la organización36. (Kent, 2006)
Las siguientes consideraciones deben ser tomadas para el diseño, implementación y adecuación de la infraestructura. 6.1.3.1 El SIEM debe ser una plataforma centralizada, todos los logs de todas las
fuentes definidas en el alcance deben ser transmitidos a la plataforma,
34 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 35 Kent, K. 36 Kent, K.
42
además hay diferentes estándares y métodos para la generación y
transmisión de los registros de datos.
6.1.3.2 La arquitectura en una infraestructura de gestión de logs, está compuesta
por las siguientes partes37. (Kent, 2006).
Los activos que generan logs llamados fuentes o generadores de logs de
datos (Dispositivos, SO, aplicaciones y servicios).
Servidores de logs, donde se efectúa el análisis y el almacenamiento.
Servidor de monitoreo, donde se encuentran las consolas para el monitoreo
de logs y reportes estadísticos e históricos, además opciones de notificaciones y
alertas.
La complejidad de la arquitectura depende de lo robusto de la infraestructura de
TI, esta guía está diseñada para el uso de SIEM de uso libre e infraestructuras de
mediana o pequeña empresa, La máquina donde se encuentra el plataforma SIEM
cumple con los requisitos de almacenamiento, análisis y monitoreo.
6.1.3.3 En caso de que las características para retención y almacenamiento sean
a largo tiempo se recomienda adicionar a la arquitectura un servidor de
copias de respaldo de los archivos de logs más antiguos.
6.1.3.4 Segmentar la red de los componentes de arquitectura de que pertenecen a
la gestión de logs o utilizar medidas de control como cifrado de los logs
que pasan a través de esta infraestructura, el motivo es evitar o reducir la
propagación de amenazas de red38. (Kent, 2006)
6.1.3.5 Características funcionales de la infraestructura de la gestión de logs. Las
siguientes son características que se deben considerar dentro de la
infraestructura para efectuar la gestión de logs, estas son soportadas por
las plataformas SIEM definidas en la presente guía39. (Kent, 2006)
La extracción de datos de logs, es muy útil para características como la
normalización, conversión y formato de los datos de forma entendible40.
37 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 38 Kent, K. 39 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 40 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
43
Filtrado de logs, para evitar falta de eficacia, gasto de recursos y tiempo, es
recomendable almacenar o tratar los logs de mayor interés filtrando aquellos que
no supongan una información útil o relevante41. (Kent, 2006)
Sumarización de eventos, la infraestructura debe ser capaz de consolidar
logs que tengan los mismos datos y convertirlo en uno solo, es útil para la
detección de ataques de fuerza bruta, además de tener una organización y reducir
consumo de recursos de almacenamiento y procesamiento42. (Kent, 2006)
Una característica para el almacenamiento de logs, es que tienen que
guardarse en archivos de logs definidos por un tamaño o por un espacio de tiempo
definido, cuando el archivo se encuentre completo es comprimido, los logs
generaran un nuevo archivo de log y sucesivamente el ciclo se repite, permitiendo
facilidad en su uso y tratamiento, esto asegura la integridad de los logs y permite
un mejor aprovechamiento de los recursos43. (Kent, 2006)
Archivado de logs, debe tener capacidad de retener y preservar los archivos
de registros por un periodo de tiempo establecido de acuerdo a las políticas de la
organización o por requerimientos regulatorios según aplique44. (Kent, 2006)
Otras características que son requeridas en la infraestructura de gestión de
logs, son la reducción de logs, conversión y normalización de los mismos, son
actividades correspondientes a la modificación de los logs con el fin de utilizarlos
en actividades como análisis, correlación y reportes estadísticos de eventos45.
(Kent, 2006)
Es fundamental también garantizar la integridad de los archivos de logs,
utilizando técnicas como firmas digitales o algoritmos de hash. También debe
mantenerse los logs en su estado original, debido a temas de investigación
forense, ya que la evidencia digital no debe alterarse.
41 Kent, K. 42 Kent, K. 43 Kent, K. 44 Kent, K. 45 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
44
En el proceso de análisis, se debe tener en cuenta que la infraestructura
debe soportar la correlación de eventos, vista de logs en un formato comprensible
y generar análisis estadísticos en función del tiempo para evaluación de la
seguridad de la información46. (Kent, 2006)
La infraestructura debe poder eliminar de forma adecuada los logs en el tiempo correspondiente a la política o requerimientos legales.
6.1.4 Generación y transmisión
Todas las fuentes de información de logs definidas en el alcance son involucrados en esta
actividad, al igual que los responsables y administradores de estos activos, debido a que
deben garantizar que estas fuentes generen sus propios registros, además de habilitar
mediante configuración el envío y filtro de los registros de logs, garantizando eficiencia y
efectividad en la gestión de logs47. (Kent, 2006)
6.1.4.1 Cada activo (Software y hardware) por su naturaleza genera registros de los cambios internos, sea informativo o a nivel crítico, en muchos de estos sistemas es necesario habilitar la generación de logs y su almacenamiento, además de su transmisión, cada activo tiene su propia configuración48, la documentación de cada fabricante o desarrollador proporciona la información para implementar los cambios sugeridos, en caso de que el responsable no tenga el conocimiento correspondiente. (Kent, 2006)
6.1.4.2 Revisión de documentación de fabricantes, desarrolladores y organizaciones de investigación sobre los tipos de logs que genera las fuentes de datos, puede obtener información concisa sobre los eventos de interés, donde se describe la clasificación de los logs, puede apoyar en la identificación para los administradores.
6.1.4.3 Filtrar los eventos de acuerdo a la experiencia obtenida en la
administración del activo49, un exceso de logs puede generar pérdidas de información, además de problemas operacionales, como se mencionó anteriormente es necesario identificar y filtra los log de interés. (Kent, 2006)
46 Kent, K. 47 Kent, K. 48 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 49 Kent, K.
45
6.1.4.4 Habilitar un protocolo para recolección y transmisión de datos que se adapte a las capacidades y diseño en los elementos de arquitectura implementados para la gestión de logs.
6.1.4.5 Que el formato generado por los protocolos para recolección y transmisión
sean soportados por la arquitectura de la gestión de logs, se debería utilizar un formato estándar y apoyarse en la documentación de los activos generadores de logs y servidores de logs o SIEM, es recomendado utilizar protocolos como syslog o bases de datos50. (Kent, 2006)
6.1.5 Retención y almacenamiento de logs
En la gestión de logs es clave definir la retención y almacenamiento de los logs, estos
requerimientos se deben especificar mediante políticas, donde se define el tipo de
almacenamiento, tamaño, costo, velocidad de recuperación, archivado y destrucción de
los logs51, a continuación se establecen algunas recomendaciones para identificar y definir
estos parámetros de acuerdo a las necesidades y regulaciones de la organización. (Kent,
2006)
Hay factores que se tienen que tener en cuenta en esta actividad dentro de la
infraestructura para la gestión de logs, como en el archivado y recuperación de los
mismos, el tiempo de retención, el formato como se almacena y las tecnologías
que pueden apoyar el proceso. (Kent, 2006)
A continuación se realizan algunas recomendaciones, para que la organización
tenga conocimiento y herramientas para adecuar esta actividad de acuerdo a
capacidades y necesidades de la organización en el proceso para retención y
almacenamiento de logs.
6.1.5.1 Es importante definir en la política las características para retención y
almacenamiento de acuerdo a las normas o regulaciones a las que se compromete la organización, ignorar el cumplimiento de estos requerimientos puede verse afectado económicamente y sancionatoriamente, debe actualizarse periódicamente la política, además cada vez que las normas regulatorias son modificadas.
50 Kent, K. Kent, K.
46
6.1.5.2 Debe definirse el tipo de logs que se van a transmitir y almacenar a la infraestructura de gestión de logs, como se ha mencionado anteriormente, no es recomendable almacenar logs que no son de interés o tienen un impacto para la organización52. (Kent, 2006)
6.1.5.3 Se deberían almacenar de logs del sistema localmente en los que si
tienen esa capacidad, esto proporciona redundancia y disminuir el riesgo de un punto único de falla53. (Kent, 2006)
6.1.5.4 Aunque es necesario que los datos de los logs sean modificados y
normalizados para actividades de análisis, correlación, fácil lectura y reportes en la infraestructura de gestión de logs54, es indispensable almacenar y mantener de acuerdo al tiempo de retención logs en su formato original, en caso de una posible investigación a nivel forense donde tiene una efectiva validez.
6.1.5.5 Definir los formatos de archivos de log cómo se almacenarán estos. se encuentra ligado con los protocolos para generación y transmisión, que sean configurados en los activos fuentes de los registros definidos anteriormente, debido a que en los campos de los diferentes formatos generados no se tiene la misma información, en algunos casos se reduce la información relevante, omitiendo ciertos detalles dentro de cada tipo de log, por lo tanto no son soportados en los sistemas de archivos de logs, por tal motivo es recomendable se utilice un sistema estándar que la mayoría de las fuentes soporten como syslog o que utilicen bases de datos estructuradas para su almacenamiento, ya que es mucho más rápido y eficiente en la recuperación y almacenamiento de datos, sobre todo en las actividades de hacer correlación, filtrado y reportes (Logging) 55. (Kent, 2006)
6.1.5.6 Aunque se encuentran varios métodos para el almacenamiento. en el caso de un sistema de archivos de logs, este debe soportar la comprensión que permite mejorar la seguridad y reducir notablemente el almacenamiento, aunque existen otros formatos como lo son los basados en texto, binarios, archivos y texto plano. Además es importante que soporte la rotación en los sistemas de archivo de log, ya que como se mencionó anteriormente, puede configurarse por tiempo o tamaño dando flexibilidad a la hora de la consulta o análisis de logs, si el sistema no lo soporta debería utilizarse aplicaciones de terceras partes 56. (CHUVAKIN, 2013)
55 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
47
6.1.5.7 Es importante definir umbrales y alarmas para monitorear el estado del almacenamiento en la infraestructura de la gestión de logs. esto por la importancia de evitar el incumplimiento y pérdida de registros, también permite como medida de prevención definir las medidas a tomar de acuerdo a las necesidades de la organización55, sin embargo en la implementación y diseño de la infraestructura de gestión de logs debe estar bien definida. Por eso se considera el tener un servidor alterno para copias de respaldo de los archivos de logs y archivado de los mismos, para retención de los logs en tiempos largos, definidos en las políticas con base en requerimientos de cumplimiento en caso que una organización aplique.
6.1.5.8 Una característica a tener en cuenta es el archivado de log, que es el almacenamiento de los archivos de log en tiempos largos para su retención, hay diferentes métodos y tecnologías, pero cada una cambia la forma y los tiempos de recuperación de la información, Se deben tener en consideración que entre mayor el tiempo de recuperación o el tiempo de almacenamiento los costos son mayores56. En el anexo G se mencionan algunas de estas tecnologías. (Chuvakin, 2013)
6.1.6 Análisis automático y correlación
En el desarrollo de la guía y en la implementación de una herramienta SIEM, se hace
necesario el análisis automático de los registros. En este proceso, se puede definir como
el paso más importante, la correlación de los eventos.
La correlación tiene como objetivo encontrar coincidencias o relaciones entre uno o varios registros de una misma fuente o diferentes fuentes. La correlación ayuda para realizar un análisis eficiente al momento de determinar un ataque o brecha de seguridad. La correlación desarrolla algunos procedimientos previos a realizar para mejorar el análisis de los registros.
El Filtro de eventos: consiste en eliminar registros duplicados, combinar eventos similares en un solo evento y en comprimir registros, para realizar un análisis rápido y efectivo.
56 CHUVAKIN, 2013.
56 CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER.
48
Normalización: Consiste en cambiar los formatos de los datos en un formato común, para los eventos puedan ser asociados por el SIEM.
6.1.6.1 Es importante que al momento de la definición, se tenga acceso a la
descripción de los campos del activo o de los activos que generan los logs
al SIEM, para identificar a cuales es posible realizar la normalización.
6.1.6.2 Uno de los principales retos que se identifican al momento de atender un
incidente de seguridad es el tiempo para identificar y reaccionar ante un
ataque, un análisis a nivel de infraestructura proporciona los mecanismos
necesarios para dar respuesta en menor tiempo y disminuir el impacto de
los incidentes de seguridad generados57. (Kent, 2006)
6.1.6.3 Definir y documentar los campos normalizados (tipo, estructura y formato),
teniendo en cuenta una futura implementación de un activo, que genere
registros para ser monitoreados por el SIEM.
6.1.6.4 Las organizaciones deben evaluar si es necesario realizar la normalización
de los campos, teniendo en cuenta que este proceso puede consumir un
alto porcentaje de recursos de la máquina que realiza el proceso58. (Kent,
2006)
6.1.7 Seguridad de los registros de logs
Aunque las herramientas SIEM, están diseñadas para prevenir e identificar incidencias de
seguridad que afecten a los activos de una organización, estas no están exentas de ser
atacadas o vulneradas, durante los procesos en los que están involucrados.
Por lo anterior se deben controlar y evaluar los posibles riesgos que se presenten en los procesos de almacenamiento, transmisión entre el activo generador, el servidor de la herramienta SIEM y el procesamiento de registros.
57 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 58 -59 Kent, K.
49
6.1.7.1 Dentro de las organizaciones se deben definir perfiles para aquellos
funcionarios que requieran acceder a los archivos de registros, de
acuerdo a la información requerida y el uso de la información.
6.1.7.2 Evitar que el registro de log contenga información clasificada como
confidencial o sensible (como contraseñas), de acuerdo a las políticas o
normas de la organización.
6.1.7.3 La información almacenada en el SIEM (base de datos o en disco), debe
cumplir con cifrado fuerte y en general con los estándares
internacionales o nacionales que le apliquen a la organización59. (Kent,
2006)
6.1.7.4 Certificar que los desarrollos requeridos para el envío, recepción,
análisis y almacenamiento no incumplan con los lineamientos de
seguridad respecto a la integridad, disponibilidad y confiabilidad de la
información de los registros.
6.1.7.5 Todo cambio, consulta y eliminación sobre los registros de logs en el
SIEM deben estar monitoreados y auditados60.
6.1.8 Notificación de alertas
De acuerdo a la política y los procedimientos que se crearon anteriormente, teniendo en
cuenta los pasos descritos en la presente guía, se deben desarrollar y parametrizar las
reglas de análisis de eventos y las notificaciones de alertas a los eventos que no cumplan
con los parámetros establecidos.
Es por esto que uno de los pasos principales indicados en la guía es el desarrollo
y planteamiento de la política de seguridad dado que lo que incumpla con la
misma es de obligatoria notificación.
6.1.9 Análisis de reportes
59 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 60 Kent, K.
50
Un paso importante en la administración y gestión de logs, es el análisis de los
reportes, estos se convierten en un apoyo y recurso para el área de seguridad en
la lucha de mitigar riesgos y reducir vulnerabilidades.
Es necesario que en las organizaciones se definan y establezcan tareas
operativas, de acuerdo a la misión y visión de la organización cumpliendo con los
objetivos propuestos en la política de seguridad, para realizar un análisis correcto
y efectivo de los reportes de registros.
6.1.9.1 En la presente guía se sugiere que se realicen tareas con diferentes
periodicidades61:
Diarias: para identificar posibles cambios en estructuras de los registros en los
últimos días, tomar acciones en un menor tiempo.
Semanal: Se sugieren realizar revisiones semanales para evaluar posibles
cambios y revisar variaciones en los sistemas.
Quincenales: Evaluar resultados de investigaciones realizadas.
Mensuales: Se recomiendan para evaluar procedimientos y estructuras de
registros.
Anuales. Se sugieren para evaluar la efectividad y ajustes de la política de
seguridad. (Kent, 2006)
6.1.10 Mitigación de incidentes Durante el análisis de los registros de logs, es posible identificar eventos de importancia como incidentes o problemas operacionales que requieran de una respuesta. Cada organización define el procedimiento para tratar estos eventos, desarrollando políticas o aplicando estándares como ITIL.
Dentro de las mejores prácticas se recomienda construir una base de
conocimientos de incidentes de seguridad, con información de vulnerabilidades
61 Kent, K.
51
conocidas, el significado de los mensajes de registro y datos que ayuden a
identificar los incidentes que se estén generando62. (Kent, 2006)
6.1.10.1 Cada persona tiene conocimientos y competencias distintas, y los
incidentes de seguridad tienden a involucrar distintos activos de la organización, es por efectividad al solucionar estos incidentes que las organizaciones deben armar grupos de trabajo, para realizar un análisis completo a los incidentes presentados.
6.1.11 Eliminación de logs
Dentro del proceso de gestión de logs, es importante generar políticas para archivar y
eliminar los registros, teniendo en cuenta los procedimientos establecidos por la
organización.
6.1.11.1 Sobrescribir los registros con mayor tiempo de antigüedad, este
proceso es viable cuando se utilizan registros de control o complementos y
no son registros vitales para las investigaciones o para realizar los análisis
de los incidentes generados63. (Kent, 2006)
6.1.11.2 Eliminar los logs de manera que no haya trazabilidad de estos
registros.
6.1.11.3 Los administradores de seguridad son los responsables de generar
las políticas para el almacenamiento de los registros por el tiempo adecuado y
generar los procedimientos de eliminación segura de acuerdo a las normas
establecidas.
62 Karen Kentrugiah, 2006. 63 Karen Kent.
52
7 DEFINICIÓN E IMPLEMENTACIÓN DE CASO DE PRUEBA
En esta sección se desarrolla un caso de prueba que está conformado por un
ambiente virtual que representa la red de una organización pequeña, en el cual se
aplicarán las actividades indicadas y desarrolladas en el capítulo anterior.
7.1 DEFINICIÓN E IMPLEMENTACIÓN DE CASO DE PRUEBA.
De acuerdo a la guía se emplean equipos importantes dentro de una
infraestructura como son los equipos de red, seguridad y servicios de una
organización como páginas WEB y sus servidores.
Para la generación y transmisión de los eventos de seguridad, se realiza la
correspondiente configuración de plugins y agentes en las fuentes de datos en
este caso los dispositivos virtuales mencionados, además se siguen las
recomendaciones de filtrar los logs de mayor importancia, además los agentes
permiten escalabilidad para integrar diferentes tipos de productos además de
ayudar en el proceso de normalización para ver e interpretar los registros de datos
de una manera fácil para su análisis, en la plataforma se puede evidenciar.
Además de mantener los logs en su estado original para el tema de investigación
forense.
En este caso de uso, los datos son almacenados en la base de datos del OSSIM,
además de su formato original, por lo que los registros son mejor tratados y es
más eficiente el tratamiento de los datos.
La plataforma genera reportes que pueden indicarnos el comportamiento de los
activos, en caso de eventos de denegación de servicio también son evidenciados
de manera rápida y efectiva en este tipo de reportes estadísticos también permite
analizar el comportamiento de los activos.
53
7.2 DESCRIPCIÓN DEL AMBIENTE
El escenario está compuesto por una infraestructura de gestión de logs
virtualizada, un servidor virtual SIEM de uso libre OSSIM, los dispositivos de red
que se integran a la infraestructura de logs son un servidor Windows 2008 con una
aplicación WEB, Firewall Cisco ASA, dos Router Cisco y además una maquina
cliente Windows 7 donde se ejecutan las pruebas de denegación de servicio y
consulta denominada atacante.
Para simular el ambiente virtual se utilizó la herramienta GNS3 que se define como
un Simulador de Red Grafico, permite emular dispositivos de red CISCO con sus
sistemas operativos reales. Para este caso se tomaron referencias de Router
CISCO con versión de sistema operativo 12.4 y Firewall ASA con versión de
software 8.4 ver Anexo H. GNS3 también permite integrar servidores virtualizados
a través de la herramienta Virtual Box en sistemas operativos Windows y Linux
(OSSIM) soportados, y es capaz de extender la red virtualizada a la red real.
Diagrama lógico de red. A continuación se detalla de manera gráfica la estructura de la red utilizada para el caso de prueba.
Figura 2. Diagrama de red
Fuente: Autor
54
Activos implementados en caso de prueba. A continuación se relacionan los activos
especificando la marca y modelo.
Cuadro2. Activos ambiente de pruebas
Activo Marca Modelo Formato de envío
de Logs
Firewall Cisco ASA5220 SYSLOG
Router Cisco 3745 SYSLOG
Servidor Windows Windows Server
2008 SYSLOG
Cliente Windows Windows 7 SYSLOG
Servidor Linux OSSIM 5.2.0 PLUGIN
Fuente: Autor
Dispositivos monitoreados por herramienta OSSIM. Para la validación de la guía se
monitorearon activos específicos de la red, que constituyen una parte importante de la red
de una organización.
Cuadro 3. Activos monitoreados
Activo Marca Direccion IP
Firewall cisco 192.168.170.1
Router Cisco 192.168.168.1
Servidor Windows 192.168.168.4
Fuente: Autor
55
7.3 DESARROLLO CASO DE PRUEBA
7.3.1 Configuración y funcionamiento OSSIM.
Para la configuración en cuanto a la captura de Logs, este posee una base de datos
definida de acuerdo con las marcas de los fabricantes de los dispositivos a monitorear,
esta configuración se activa seleccionando el plugin correspondiente a marca y modelo de
los dispositivos o activos detectados, en el caso de prueba se utilizan los llamados
CISCO-ASA para el firewall, CISCO-ROUTER para el Router, INTERSECT ALIANCE para
el servidor de aplicación WEB Windows 2008 el cual requiere la instalación de un
aplicativo para la transmisión de los registros de datos, para el presente trabajo se utilizó
la aplicación SNARE, teniendo en cuenta que es de uso libre y su fácil instalación y
configuración, el cual realiza un reenvío de los eventos del visor de eventos de Windows
al SIEM.
Para la evaluación Ossim permite la generación de reportes estadísticos y
gerenciales para verificar y analizar la gestión realizada sobre los registros de
datos (logs), permitiendo diagnosticar y evaluar los eventos presentados. En el
Anexo I, se presentan algunas de las gráficas que permite generar la herramienta
y que se utilizaron para evaluar las actividades planteadas en la guía metodológica
y adicionalmente la descripción de cada una de ellas.
7.3.2 Resultados de la prueba
A continuación se detalla el resultado de la evaluación funcional del SIEM.
Se ejecutan pruebas que verifican la efectividad del SIEM para colectar y
normalizar los eventos de los activos descritos anteriormente.
Para esta evaluación se utiliza el siguiente formato el cual puede ser utilizado para
evaluar la implementación de la guía metodológica desarrollada en el presente
trabajo.
Se evidencia que se capturaron en su totalidad los eventos enviados por los
diferentes activos, concluyendo que no hay pérdida de paquetes ni error en la
captura por una inadecuada configuración.
56
Cuadro 4. Estadísticas del caso de prueba
Estadísticas documentadas en caso de prueba
Fecha 05/11/2015
Hora 20:00 – 22:00
EVIDENCIA GENERADOR PRUEBAS DESCRIPCIÓN CANTIDAD
REGISTROS
EN LA
FUENTE
REGISTROS
EN EL SIEM
EFECTIVIDAD
(%)
Captura de
pantalla
Fuente de
Logs
Nombre de la
Prueba (Acceso,
Modificación,
Cambio)
Descripción de
la prueba
# de
Pruebas
# Registros
generados
por la
fuente
# Registros
capturados
SIEM
# Registros
fuente/#
Registros
capturados
SIEM
1 Firewall
Acceso
denegado
Se realiza
intento de
ingreso a
servicio no
permitido de
escritorio
remoto
5 5 5 100%
2 Router
Acceso
permitido
Se realiza
ingreso a
página Web
permitida
5 5 5 100%
3 Windows
Reinicio de
servicio por
modificación
Se reinicia
servicio IIS 5 5 5 100%
4 Router
Cambio de
configuración
Se realiza
cambio de
configuración
en Router
5 5 5 100%
5 Firewall
Correlación de
eventos
Se realiza
ataque con
herramienta
DoS
5 50 50 100%
Fuente: Autor
57
En el Anexo J se muestran las evidencias de la transmisión y captura de logs para
cada uno de los casos de prueba.
58
8. CONCLUSIONES
Mediante el desarrollo del presente trabajo, se identificaron actividades que
generan una guía metodológica, para la gestión de registros de seguridad, por
medio de un SIEM de uso libre.
Las actividades propuestas en la guía metodológica se consideraron por medio del
estudio de normas, estándares y modelos de buenas prácticas, finalmente se
evaluaron en un ambiente de pruebas.
A continuación se describen las conclusiones y resultados que se obtuvieron en el
desarrollo del presente trabajo:
Se recomienda seguir las actividades propuestas en la guía, para que el proceso
de gestión de logs tenga consistencia y efectividad. Se debe tener en cuenta, que
dependiendo de la estructura de la empresa, es posible obviar o adicionar algunas
de las actividades aquí propuestas.
La infraestructura de gestión de logs, varía de acuerdo a la cantidad de fuentes de
datos integrados en el proceso y la cantidad de logs que estos generan, debido a
esto, es importante en el diseño e implementación de la infraestructura tener en
cuenta los recursos necesarios para cumplir los objetivos del proceso, por tal
motivo cada organización no puede imitar o guiarse por la infraestructura de otras
organizaciones.
El caso de prueba, está enfocado en las actividades y capacidades que ofrece un
SIEM de uso libre como la generación y transmisión de logs, el análisis, la
correlación e implementación de arquitectura de logs.
El uso de un SIEM (centralización de registros de datos), como parte fundamental
de la arquitectura de gestión de registros de datos (logs), proporciona información
fácil de diagnosticar y de leer, generando un valor a la seguridad de la información
debido al proceso de rapidez y automatización para identificar en menor tiempo un
evento de impacto a la infraestructura.
Las limitaciones de una herramienta de uso libre son evidentes en organizaciones
con infraestructura tecnológica grandes, debido a la cantidad de recursos
necesarios para el análisis y correlación, además de temas como almacenamiento
y seguridad.
59
Se evidencia al momento de las pruebas que las características mínimas de
funcionamiento recomendadas por los proveedores, generan problemas de
rendimiento aún con pocos equipos configurados en la red.
A pesar que la integración escalable en plataformas de uso libre, se pudo
determinar que la complejidad en la configuración de la herramienta y la poca
documentación certificada que se encuentra, es una desventaja al momento de
implementar una herramienta SIEM, dado que se requiere de un nivel de
habilidades técnicas, conocimientos en Linux, programación, redes, seguridad
informática y destreza en la herramienta.
60
BIBLIOGRAFIA
Alertlogic. (10 de 5 de 2015). Alertlogic. Obtenido de Alertlogic: http://www.alertlogic.com/wp-content/uploads/2012/01/Log-Management-Best-Practices.pdf
ALIENVAULT, O. . (17 de 8 de 2015). OSSIM - ALIENVAULT. Obtenido de OSSIM - ALIENVAULT: https://www.alienvault.com/products/ossim
Arcsigth. (10 de 5 de 2015). Arcsigth. Obtenido de Arcsigth: http://www.arrowecs.es/ficheros/partners/3_WhitePaper_ArcSight_Log_Management.pdf
Chris, L. (24 de 10 de 2015). Cisco Systems The BSD Syslog Protocol. Obtenido de Cisco Systems The BSD Syslog Protocol: http://www.ietf.org/rfc/rfc3164.txt
CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER. Obtenido de ELSEVIER: https://www.elsevier.com/books/logging-and-log-management/chuvakin/978-1-59749-635-3
Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision . Obtenido de EMC-RSA Envision : http://www.eircomictdirect.ie/docs/rsa/envision-wp.pdf
Graylog. (7 de 8 de 2015). Graylog. Obtenido de Graylog: http://docs.graylog.org/en/latest/
Ipswitch. (9 de 5 de 2015). Ipswitch . Obtenido de Ipswitch : http://www.enterprisemanagement360.com/wp-content/files_mf/white_paper/elm_whitepaper_9-30-10.pdf
Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. Obtenido de National Institute of Standars and Technology: http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf
Ltda., L. Z. (17 de 8 de 2015). LOGALYZE Zuriel Ltda. Obtenido de LOGALYZE Zuriel Ltda. : http://www.logalyze.com/installation-manual/finish/1-documentation/12-logalyze-installation-manual
61
OSSEC. (16 de 8 de 2015). OSSEC. Obtenido de OSSEC: http://www.ossec.net/?page_id=165
PRELUDE. (16 de 8 de 2015). PRELUDE. Obtenido de PRELUDE: http://www.prelude-siem.com/index.php/uk/products/87-products/97-prelude-presentation-uk
Securosis. (25 de 8 de 2010). Securosis. Obtenido de Securosis: https://securosis.com/assets/library/reports/Securosis_Understanding_Selecting_SIEM_LM_FINAL.pdf
Shenk, J. (25 de ABRIL de 2015). SANS INSTITUTE. Obtenido de SANS INSTITUTE: http://www.sans.org/reading-room/whitepapers/analyst/eighth-annual-2012-log-event-management-survey-results-sorting-noise-35230
Swift, D. (3 de 5 de 2015). SANS Institute. Obtenido de SANS Institute: http://www.sans.org/reading-room/whitepapers/auditing/successful-siem-log-management-strategies-audit-compliance-33528
Task, J. (26 de 4 de 2015). National Institute of Standars and Technology. Obtenido de National Institute of Standars and Technology: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
Task, J. (25 de Abril de 2015). National Instituto of Standars and Tecnology. Obtenido de National Instituto of Standars and Tecnology: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf
62
ANEXO A.
COSTO DE PLATAFORMA SIEM DE ALLIENVAULT
Se relaciona el costo de implementación de la plataforma SIEM de AllienVault.
63
ANEXO B.
COSTO DE PLATAFORMA QRADAR PRODUCTO DE IBM.
A continuación se relacionan los costos que puede tener la plataforma QRADAR, de acuerdo a las necesidades de la empresa, sin los costos de los servidores e implementación.
64
ANEXO C.
FUENTES ORIGINADORAS DE LOGS
Se mencionan algunas fuentes originadoras de logs, que tienen eventos de interés para la seguridad de la información de una organización.
65
Sistemas de Prevención de Intrusos (IPS)
Estos sistemas son de seguridad perimetral
escanea frecuentemente el trafico de redes
externas para hallar y bloquear trafico, sus
mecanismos son avanzados trabajos sobre
firmas y es capaz de detectar ataques por su
comportamiento o data escondida sobre
paquetes.
Servidores de correo
El correo es una herramienta en muy
importante en los procesos de negoción
actualmente, lo que sugiere un activo
importante para su control y monitoreo
Servidores Proxy
Son plataformas que ayudan a la seguridad
de la información, ya que limitan accesos a
internet, reduciendo riesgos de servicios
que amenazan la seguridad y evitando el
uso de protocolos o puertos vulnerables
Servidores de Aplicación
Soportan las aplicaciones que se tiene
publicar ya sea internas o externas y es
necesarion controlar sus logs para
evidenciar ataques o modificaciones a nivel
de servicio, debido a que son fuentes que
pueden impactar un servicio
Aplicaciones
Son los desarrollos que tienen un fin en
muchos casos son fundamentales para el
core de negocio de una organización, se
debe monitorear u cambio en el software
para evitar la caida de la aplicación
Firewalls de Aplicación
Con la evolución de los ataque ciberneticos
se crean nuevas solucines, algunas
organizaciones cuentan con un Firewall de
aplicación enfocado en proteger el software
y todos los ataque a nivel de aplicación.
66
ANEXO D
RESPONSABILIDADES EN EL PROCESO DE GESTIÓN DE LOGS
Se da una breve referencia sobre la distribución de las actividades de gestión de logs a partir de una matriz de responsabilidades.
ROL RESPONSABILIDAD
Lider de TI
Responsable de evaluar la gestión de logs, recibir
informes tecnicos de las actividades de los otros roles en
la gestión de logs, comunicar a la alta gerencia sobre el
desempeño y las actividades concernientes al proceso de
gestión de logs.
Administradores de red y de servidores
Responsable por configurar cada sistema involucrado en
la infraestructura de gestion de logs, periodicamente
revisar y analizar los logs localmente, mantener los logs y
que se esten generando de manera correcta los logs y
reportar los resultados de las actividades a la gestion de
logs
Administrador de seguridad
Responsable de monitorear y administrar la
infraestructura para la gestión de logs, configurar los
dispositivos de seguridad para la generación y
transmisión de logs, documentar los reportes de las
actividades para la gestión de logs, apoyar en el analisis
de los logs en incidentes o requerimientos.
Equipos de respuesta a incidentes
El equipo debe ser compuesto por los administradores de
red y seguridad, un equipo especializado encargado del
analisis de logs y respuesta ante incidentes en la
organización
Desarrolladores de aplicaciones
Aplicar en el diseño y ajustes de las aplicaciones los
requerimientos para la gestion de logs, como generación
de logs, transmisión, clasificación, valoración y definición
de formatos con la información apropiado de los eventos
que deben generar.
Auditores
Encargados para el uso de datos dentro de los logs para
evidencia en auditorias para cumplimiento y procesos
desarrollados en la organización.
67
ANEXO E
CLASIFICACIÓN DE LOGS
Se describen algunos tipos de logs y como se categorizan de acuerdo a su severidad, algunos activos y protocolos propietarios difieren en su clasificación.
TIPOS DE LOGS DESCRIPCIÓN
Gestión de cambios
Este tipo de logs registra cambios en el sistema, en sus
componentes, actualizaciones, cambios de cuentas y
todo tipo de cambio que altere el sistema asi sea
minimo. Este tipo de logs generalmente se divide en
estos estaodos agregar, eliminar,actualizar y modificar
registros
Autenticación y Autorización
Los registros decisiones de autorización y
autenticación como como éxito o falla en el login a un
dispositivo, estos mensajes de seguridad ofrece
utilidad cuando se realiza trazabilidad del agun
evento, son relativos acceso a la red o dispositivos.
Acceso al sistema y la información
Es relativo a los logs de autenticación, registros de
acceso a un archivo, bases de datos o aplicación. Son
utiles para encontrar eventos de seguridad y de
rendimiento.
Gestión de Amenazas
Son logs generados como alertas de intrusion a un
sistema como violación de politicas, son generados
por equipos de red y seguridad.
Rendimiento y Gestión de Capacidad
Son relacionados al rendimiento y capacidad del
sistema, incluyen umbrales de capacidad y
rendimiento del sistema se categorizan como
mensajes operacionales, muy importantes encontrar
fallas de seguridad
Continuidad de Negocio y Gastion de Disponibilidad
Los sistemas registran cuando es apagado o reiniciado,
y otros mensajes realitivos a continuidad como
backups, redundancia o utilización.
Miscelania de errores y fallas
Este tipo de logs son relativos a errores del sistema,
cada uno esta diseñado con unos eventos clasificados
en su etapa de diseño para advertir a administradores
o usuarios para su revisión y toma de medidas
preventivas, estos no llegan a ser mensajes
operacionales criticos que necesitan una acción
rapida.
Miscelania de mensajes de depuración
Los logs de depuración o debug, son todos los
mensajes que no son faciles de clasificar, la mayoria
no son habilitados en ambientes de producción
operacionales, provocan otros riesgos a los sistemas
ademas no son utilis para evidenciar eventos de
seguridad.
68
CATEGORIAS DESCRIPCIÓN
Informational
Son mensajes diseñados para permitir
conocer que algo a ha ocurrido, algo
normal, descartando algun tema de
seguridad.
Debug
Son mensajes depurados generados
por el software del sistema ayudan a
identificar problemas a los
desarrolladores, pero no identifican
un impacto negativo en el sistema
Warning
Son mensajes concerniente a
situaciones donde se han perdido algo
del sistema pero no impacta la
operación.
Error
Son mensajes que ocurren sobre
varios niveles en un sistema de
computo sobre errores y dan un
indicio de la causa del error,
normalmente la operación puede
continuar, aunque se puede ver
degradado el sistema.
Alert
Indican eventos de seguridad han
ocurrido, estos eventos necesitan de
una accion para corregir, el sistema
puede ser impactado seriamente,
normalmente son equipos de
seguridad y de red los que generan
este tipo de logs
69
ANEXO F
EJEMPLO POLÍTICA PARA LA GESTIÓN DE LOGS.
Se menciona un ejemplo para el desarrollo de una política para el proceso de gestión de logs, se espera detallar las necesidades y el direccionamiento del proceso.
ARQUITECTURA DE
GESTIÓN DE LOGS
Se debe disponer de medios tecnológicos para la gestión centralizada de logs,
que garantice la operación, tratamiento de logs, análisis, almacenamiento,
retención y disposición de los registros.
SINCRONIZACIÓN DEL
TIEMPO
Los sistemas de procesamientos de logs deben garantizar exactitud en sus
registros para disponer de medidas fiables en los registros de todos los sistemas
de información, mediante la correcta configuración de sus relojes, se debe validar
su exactitud con fuentes externas y monitorear la desviación que se produzca.
RETENCIÓN DE LOGSSe deben retener los log de acuerdo a la ley HIPPA, la cual la organización tiene
el deber de cumplir.
ALMACENAMIENTO DE
LOGS
El área de TI debe respaldar el almacenamiento de logs mediante tecnologías
confiables y eficientes asegurando la disponibilidad de los logs, se debe asegurar
un respaldo en las unidades de almacenamiento de los archivos de logs, y
proveer de los controles de acceso a esta información a personal autorizado.
SEGURIDAD DE LOGS
Se debe asegurar la confidencialidad, integridad autenticidad de los logs a través
de su ciclo de vida, con los controles adecuados con el fin de evitar algún fraude
informático.
MONITOREO
Es necesario que se cuente con un sistema de monitoreo de los registros que
genere alertas en caso de una situación inusual.
ELIMINACIÓN
Se debe contar con métodos y herramientas efectivas para la eliminación de
registros sin comprometer la fuga de información y que no quede traza alguna de
los logs.
POLITICA GESTION DE LOGS
El área de sistemas de la información está encargada de asegurar la gestión de logs como
soporte operativo y de seguridad de la organización, garantizando continuidad, seguridad y
reducción en el impacto de los procesos estratégicos de la organización, La responsabilidad de
la gestión es del ingeniero de seguridad de la organización quien debe asegurar la operación,
monitoreo, remediación de fallas y actualización del proceso.
Se deben asegurar la generación de registros de auditoria y de seguridad en los sistemas
críticos para los procesos de la organización.
Los responsables de los registros serán los administradores de cada uno de los sistemas
quienes tendrán que asegurar la generación y transmisión de los mismos, además de definir y
filtrar los eventos de mayor impacto en sus sistemas para su tratamiento.
70
ANEXO G
TECNOLOGIAS PARA ALMACENAMIENTO
Se define una matriz de las tecnologías de almacenamiento para la infraestructura
de gestión de logs, se especifican algunas características, información útil para
diseñar las opciones de almacenamiento y retención en la infraestructura para la
gestión de logs.
TECNOLOGIA DE ALMACENAMIENTO DESCRIPCIÓN CARACTERISTICAS
Discos Duro - Unidad de Disco Rigido
Son unidades de gran capacidad y normalmente se encuentran internos dentro
de un mismo equipo de computo, esta formados por varios discos apilados
sobre los que leen y escriben información a traves de una cabeza magnetica,
estos almacenan datos para ser accedidos de forma inmediata y automatica
pero aun tiene limitaciones en velocidad, pero por estar en dentro
internamente dentro de un dispositivo tiene gran riesgo de falla, Los Discos
rigidos externos tampoco se consolidan como fiables para respaldos de
empresas por su fabricación y sus unidades mecanicas.
Puede tener un tiempo largo, es economico pero
al compartir recursos con otros servicios de
computo tiene un riesgo amplio de perdida y
falla, ademas la recuperacion de los datos es
rapida y automatica
Unidad de Disco Optico CD, DVD y Blueray
Son unidades externas de almacenamiento que necesitan un lector optico para
leer o escribir en las pistas del disco, las diferentes tecnologias cambian en
capacidad (CD, DVD, Bluray)
Tienen un tiempo de vida corto, hay discos con
gran almacenamiento, es portable, economico
pero no es eficiente para recuperar datos
Unidad de Estado Solido (USB, Flash)Se basan en una tecnologia de memoria no volatil, hecho con componentes
electronicos, con velocidades de transmisión altas.
Limitado almacenamiento, en algunos casos es
costoso, la transmision es rapido sin embargo la
recuperación es igual al de disco opticos manual
y con untiempo mas largo.
Cintas Magneticas
Son de gran capacidad, tiene su uso para copias de respaldo, las tecnologias y
formatos cambian su capacidad de velocidad de transmisión y
almacenameinto, algunos son DAT, DDS, DLT y LTO
Es especial para realizar backups y retener por
tiempos largos, no es costoso y tienen tiempo de
vida moderado, algunas caracteristicas de
velocidad de transmisión es aceptable para los
sistemas, no es automatico para la recuperación
por que debe ser con intervención humana.
ALMACENAMIENTO SAN
Es una arquitectura completa para el almacenamiento con diferentes
componentes desde switches e alta velocidad y sistemas con discos duros
rigidos o de estado solido
Es posible configurar una arquitectura, que es
muy eficiente para la recuperación y control
sobre el almaenamiento ademas se puede ir
actualizando periodicamente evitando perdidas
sin embargo es un escenario muy costoso.
71
ANEXO H.
DIAGRAMA DE RED CONFIGURADO PLATAFORMA GNS3
Se muestra la estructura de red diseñada en la plataforma virtual, para el
desarrollo de las pruebas.
72
ANEXO I
GRAFICAS Y REPORTES DE LA HERRAMIENTA SIEM
Se muestran reportes generales de los tipos de logs, que permiten enfocar y definir las actividades para los tipos de Logs a analizar.
Se observa la cantidad de tipos de logs por cada fuente de datos, esto permite una
mejor visualización de su comportamiento.
73
74
Graficas que indica la tendencia de los logs, de acuerdo a los tipos y fuentes.
75
Lista general de Eventos Capturados por el OSSIM
76
ANEXO J.
EVIDENCIA CAPTURA DE PANTALLA PARA LOGS GENERADOS
1. Captura de logs prueba acceso denegado
77
78
2. Captura de logs acceso permitido
79
3. Captura logs reinicio de servicio por modificación
80
81
4. Captura de logs por cambio en configuración de interfaz de red
82
83
5. Captura logs correlación por detección de ataque denegación de servicio
84
85
ANEXO K.
ESTRUCTURA DE LA GUÍA METODOLÓGICA
En esta guía se detallan recomendaciones generales operativas y técnicas, respecto a las actividades para desarrollar e implementar la gestión de registros de datos (logs) manera eficiente, apoyados en estándar NIST SP800-92 y las consideraciones evaluadas en el documento.
1. GUÍA METODOLÓGICA
De acuerdo a la investigación y al soporte de algunos estándares y organizaciones de investigación como la NIST, la guía se divide en las siguientes actividades para lograr que la gestión de logs se encuentre dentro de un marco fundamental para la seguridad de la información de la organización. Las actividades aquí propuestas son implementadas o desarrolladas dependiendo de la necesidad y actividad de la organización.
Definición de alcance: Definir que plataformas y tipos de logs que harán parte del proceso de gestión.
Políticas y Procedimientos: Generación de Políticas y Procedimientos que puedan formalizar e implementar el proceso de gestión de logs.
Infraestructura para la Gestión de logs: Cada organización de acuerdo a sus necesidades, debe adecuar una infraestructura para la gestión de Logs.
Generación y Transmisión: Asegura que los registros de logs de las plataformas definidas en el alcance sean generados y transmitidos a la plataforma de gestión de logs.
Retención y Almacenamiento: Definir requerimientos y políticas para retención y almacenamiento de logs
Análisis Automático y Correlación: Implementar y ajustar mecanismos automáticos para el análisis y correlación de logs
Seguridad de los registro de logs: Implementar mecanismos de seguridad para protección de logs en las actividades de recolección, transmisión, almacenamiento y retención.
Notificación de alertas: Establecer y configurar medios de notificación de alertas
Análisis de reportes: Configurar y ajustar reportes estadísticos e históricos para validación de comportamientos de la infraestructura tecnológica.
Mitigación de incidentes: Establecer procedimientos gestión de incidentes para mitigar las amenazas identificadas y reportadas mediante la gestión de logs.
86
Eliminación de logs: Aplicar procedimientos y políticas para la eliminación apropiada de logs.
A continuación se describen en detalle cada una de las actividades.
Definición del alcance. En esta etapa se debe definir los componentes que son
involucrados en la gestión de logs.
La definición del alcance es fundamental en el proceso de gestión de los registros
de datos, debido a que la ausencia, omisión o adición de alguna fuente de logs
que pueda impactar los servicios o procesos de la organización, mantiene un
riesgo alto que se materialice un incidente debido a que no hay un monitoreo de
esos logs, además de no conseguir una respuesta reactiva efectiva y rápida.
87
Dispositivos de hardware o software. Se recomienda identificar los activos ya sea
software o hardware que tengan más criticidad para el negocio, algunas de las
herramientas que ayudan a realizar esto es mediante reuniones y entrevistas con
los responsables de los activos, metodologías para valorar riesgos e impactos e
inventario de activos. En el anexo C, se detallan algunos de los dispositivos de
hardware, que se consideran de gran impacto para la organización, cabe señalar
que cada organización tiene su propia infraestructura de TI y la importancia de
sus activos dependen de sus necesidades de negocio64. (Chuvakin, 2013)
8.1.1.1 Responsables en el proceso de gestión de logs. Definir las
responsabilidades dentro del proceso de gestión de logs, para que la
gestión sea adecuada, se identifiquen las actividades de cada rol con
respecto a los logs y definir las personas que se encuentran involucradas
en el proceso65. (Kent, 2006). El anexo D establece un ejemplo de los
roles involucrados en el proceso de gestión de logs.
8.1.1.2 Tipos de logs. Los sistemas de información generan varios tipos de
registros de datos (logs), algunos son eventos no relevantes, por lo tanto es
necesario realizar un filtro de los logs que generan más impacto para cada uno de
los sistemas de información, la responsabilidad de definir los registros que serán
tratados en el proceso de gestión de logs es el dueño de cada activo, debido a que
identifica que registros de datos sugieren un monitoreo y análisis dado que es la
persona que mejor conoce muy bien el sistema de información66. En el anexo E
se mencionan las categorías y tipos de logs que las fuentes pueden generar, muy
útil para su filtro.
8.1.1.3 Infraestructura para la gestión logs. En el alcance se debe definir con
que infraestructura se va a contar para implementar la gestión de registros de
datos (logs), Se debe realizar una caracterización en el diseño y la implementación
de la infraestructura para la gestión de logs de acuerdo al alcance, tiempos de
retención, dispositivos tecnológicos (SIEM, Servidor SYSLOG), forma de
almacenamiento, controles de seguridad, forma de transmisión capacidad de los
recursos como procesamiento, memoria y ancho de banda, además de los
recursos físicos y personales para su gestión.
64 CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER. 65 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 66 CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER.
88
Crear una política y procedimientos para la gestión de Logs. La política debe ser clara y
concisa con los requerimientos y recomendaciones para la gestión de logs, debe estar
enfocada y alineada a la misión y visión de cada organización, Se debe tener definido de
acuerdo a las necesidades de negocio y cumplimiento de acuerdo a las normas
regulatorias que aplique, En el anexo F Se da un ejemplo de una política de gestión de
acceso siguiendo las recomendaciones expuestas.
Los procedimientos fundamentan y apoyan la política de gestión de logs a nivel operativo, estos detallan la operación, soporte y monitoreo del proceso, al igual que en la política se deben ser claros y efectivos en la comunicación, debe especificar las actividades y responsabilidades dentro del proceso de la gestión de logs. 8.1.2.1 Se deben establecer los requerimientos en caso de que aplique a la
organización referente a67:
Generación de logs.
Transmisión de logs.
Almacenamiento de logs.
Disposición de los logs.
Análisis de logs.
Seguridad de los logs. (Kent, 2006)
8.1.2.2 Establecer políticas que se puedan cumplir. Que no amenace con la
interrupción o disponibilidad de los procesos estratégicos o de negocio de una
organización.
Definir un alcance correcto. Sin ambigüedad evitando ausencia de responsabilidad
o falta de compromiso con el proceso de gestión de logs68. (Kent, 2006)
La política debe ser revisada periódicamente. Cada vez que hayan cambios en la
infraestructura de tecnología, en caso de necesitar actualización debe ser
generada para mantener el proceso alineado con los propósitos de la
organización.
Especificar los eventos más significativos para su tratamiento y análisis.
67 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 68 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
89
Hacer referencia a normas y regulaciones. Que se encuentren relacionadas dentro de la gestión de logs y deban ser aplicadas de acuerdo al negocio de una organización69.
Infraestructura gestión de Logs. La presente guía sugiere el uso de una
herramienta SIEM de uso libre como dispositivo central para la gestión de
logs, el dispositivo es un software el cual debe ser instalado en una máquina
que garantice los recursos evaluados en la definición del alcance, además
del estimado del crecimiento en el futuro de la organización70. (Kent, 2006)
Las siguientes consideraciones deben ser tomadas para el diseño, implementación
y adecuación de la infraestructura. El SIEM debe ser una plataforma centralizada,
todos los logs de todas las fuentes definidas en el alcance deben ser transmitidos
a la plataforma, hay diferentes estándares y métodos para la generación y
transmisión de los registros de datos.
8.1.5.2 La arquitectura en una infraestructura de gestión de logs, está
conformada en las siguientes partes71. (Kent, 2006)
Los activos que generan logs llamados fuentes o generadores de logs (Dispositivos, SO, aplicaciones y servicios).
Servidores de logs donde se efectúa el análisis y el almacenamiento.
Servidor de monitoreo, donde se encuentran las consolas para el monitoreo de logs y reportes estadísticos e históricos, además opciones de notificaciones y alertas. La complejidad de la arquitectura depende de lo robusto de la infraestructura de
TI, esta guía está diseñada para el uso SIEM de uso libre e infraestructuras de
69 Kent, k.
70 Karen Kent, 10 de Octubre/2015.
71 Karen Kent, Murugiah Souppaya National Institute of Stand Technology, 2006
Septiembre.
90
mediana o pequeña empresa, La máquina donde se encuentra el plataforma SIEM
cumple con los requisitos de almacenamiento, análisis y monitoreo.
8.1.5.3 En caso de que las características para retención y almacenamiento
sean a largo tiempo se recomienda adicionar a la arquitectura un servidor de
copias de respaldo de los archivos de logs más antiguos.
8.1.5.4 Segmentar la red de los componentes de arquitectura de que
pertenecen a la gestión de logs o utilizar medidas de control como cifrado de
los logs que pasan a través de esta infraestructura, el motivo es evitar o
reducir la propagación de amenazas de red72. (Kent, 2006)
8.1.5.5 Características funcionales de la infraestructura de la gestión de logs.
Las siguientes son características que se deben considerar dentro de la
infraestructura para efectuar la gestión de logs, estas son soportadas por las
plataformas SiEM definidas en la presente guía73.
La extracción de datos de logs, es muy útil para características como la
normalización, conversión y vista de los datos de forma entendible74.
Filtrado de logs, para evitar falta de eficacia, gasto de recursos y tiempo, es
recomendable almacenar o tratar los logs de mayor interés filtrando aquellos
que no supongan una información útil o relevante75.
72 Karen Kent, Murugiah Souppaya National Institute of Standards and Technology, 2006
Septiembre.
73 Karen Kent, Murugiah Souppaya National Institute of Standards and Technology, 2006 Septiembre, Sitio Web, 10 de Octubre/2015.
74 Karen Kent, Murugiah Souppaya National Institute of Standards and Technology, 2006 Septiembre, Sitio Web:, 10 de Octubre/2015
75 Karen Keitute of Standards and Technology, 2006 Septiembre.
91
Sumarización de eventos, la infraestructura debe ser capaz de consolidar
logs que tengan los mismos datos y convertirlo en uno solo, es útil para la
detección de ataques de fuerza bruta, además de tener una organización y
reducir consumo de recursos de almacenamiento y procesamiento76.
Una característica para el almacenamiento de logs, es que tienen que
guardarse en archivos de logs definidos por un tamaño o por un espacio de
tiempo definido, cuando el archivo se encuentre completo es comprimido, los
logs generaran un nuevo archivo de log y sucesivamente el ciclo se repite,
permitiendo facilidad en su uso y tratamiento, asegura la integridad de los
logs y permite un mejor aprovechamiento de los recursos77. (Kent, 2006)
Archivado de logs, debe tener capacidad de retener y preservar los archivos
de registros por un periodo de tiempo establecido por las políticas de la
organización o por requerimientos regulatorios según aplique78.
Otras características que son requeridas en la infraestructura de gestión de
logs, son la reducción de logs, conversión y normalización de los mismos,
son actividades correspondientes a la modificación de los logs con el fin de
utilizarlos en actividades como análisis, correlación y reportes estadísticos de
eventos79.
Es fundamental también garantizar la integridad de los archivos de logs,
utilizando técnicas como firmas digitales o algoritmos de hash. También debe
76 Kent, k.
77 Kent, k.
78 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
79 Kent, k.
92
mantenerse los logs en su estado original, debido a temas de investigación
forense, la evidencia digital no debe alterarse.
En el proceso de análisis, se debe tener en cuenta que la infraestructura
debe soportar la correlación de eventos, vista de logs en un formato
comprensible y generar análisis estadísticos en función del tiempo para
evaluación de la seguridad de la información80.
La infraestructura debe poder eliminar de forma adecuada los logs en el
tiempo correspondiente a la política o requerimientos legales.
Generación y transmisión. Todas las fuentes de información de logs definidas
en el alcance son involucrados en esta actividad, al igual que los
responsables y administradores de estos activos, debido a que deben
garantizar que estas fuentes generen sus propios registros, además de
habilitar mediante configuración el envío y filtro de los registros de logs,
garantizando eficiencia y efectividad en la gestión de logs81. (Kent, 2006)
80 Kent, k.
81 Kent, k.
93
8.1.5.6 Cada activo (Software y hardware) por su naturaleza genera registros
de los cambios internos, sea informativo o a nivel crítico, en muchos de estos
sistemas es necesario habilitar la generación y su almacenamiento, además
de su transmisión, cada activo tiene su propia configuración82 (Kent, 2006)
8.1.5.7 , la documentación de cada fabricante o desarrollador proporciona la
información para implementar los cambios sugeridos, en caso de que el
responsable no tenga el conocimiento correspondiente.
8.1.5.8 Revisión de documentación de fabricantes, desarrolladores y
organizaciones de investigación sobre los tipos de logs que genera la fuente,
puede obtener información concisa sobre los eventos de interés, donde se
describe la clasificación de los logs, puede apoyar en la identificación para los
administradores.
8.1.5.9 Filtrar los eventos de acuerdo a la experiencia obtenida en la
administración del activo83, un exceso de logs puede generar pérdidas de
información adema de problemas operacionales, como se mencionó
anteriormente es necesario identificar y filtra los log de interés. (Kent, 2006)
8.1.5.10 Habilitar un protocolo para recolección y transmisión de datos que se
adapte a las capacidades y diseño en los elementos de arquitectura
implementados para la gestión de logs.
8.1.5.11 Que el formato generado por los protocolos para recolección y
transmisión sean soportados por la arquitectura de la gestión de logs, se
debería utilizar un formato estándar y apoyarse en la documentación de los
activos generadores de logs y servidores de logs o SIEM, es recomendado
utilizar protocolos como syslog o bases de datos84. (Kent, 2006)
82 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
83 Kent, k.
84 Kent, k.
94
Retención y almacenamiento de logs. En la gestión de logs es clave definir la retención y
almacenamiento de los logs, estos requerimientos se deben especificar mediante
políticas, donde se define requerimientos como tipo de almacenamiento, tamaño, costo,
velocidad de recuperación, archivado y destrucción de los logs85, a continuación se
establecen algunas recomendaciones para identificar y definir estos parámetros de
acuerdo a las necesidades y regulaciones de la organización.
Hay factores que se tienen que tener en cuenta en esta actividad dentro de la infraestructura para la gestión de logs, en el archivado y recuperación de los mismos, el tiempo de retención, el formato como se almacena y las tecnologías que pueden apoyar el proceso86. (Kent, 2006)
A continuación se realizan algunas recomendaciones, para que la organización tenga conocimiento y herramientas para adecuar esta actividad de acuerdo a capacidades y necesidades de la organización en el proceso para retención y almacenamiento de logs. 8.1.7.1 Es importante definir en la política las características para retención y
almacenamiento de acuerdo a las normas o regulaciones a las que se
comprometer la organización, ignorar el cumplimiento de estos requerimientos
puede verse afectado económicamente y sancionatoriamente, debe actualizarse
periódicamente o si las normas regulatorias son modificadas.
8.1.7.2 Debe definirse el tipo de logs que se van a transmitir y almacenar a
la infraestructura de gestión de logs, como se ha mencionado no es
recomendable almacenar logs que no es de interés o un impacto para la
organización87.
(Kent, 2006)
85 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
86 CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER.
87 Kent, k.
95
8.1.7.3 Se deberían almacenar de logs del sistema localmente en los, si
tienen esa capacidad, esto proporciona redundancia y disminuir el riesgo de
un punto único de falla88. (Kent, 2006)
8.1.7.4 Aunque es necesario que los datos de los logs sean modificados y
normalizados para actividades de análisis, correlación, fácil lectura y reportes
en la infraestructura de gestión de logs89, es indispensable almacenar y
mantener de acuerdo al tiempo de retención logs en su formato original, en
caso de una posible investigación a nivel forense donde tiene una efectiva
validez. (Kent, 2006)
8.1.7.5 Definir los formatos de archivos de log cómo se almacenarán los logs
se encuentra ligado con los protocolos para generación y transmisión que
sean configurados en los activos que originan los registros, definidos
anteriormente, debido a que en los diferentes formatos generados no se tiene
la misma información, en algunos casos reduce a información relevante
omitiendo ciertos detalles dentro de cada tipo de log, por lo tanto no son
soportados sistemas de archivos de logs por eso es recomendable se utilice
un sistema estándar que la mayoría de las fuentes soporten como syslog o
que utilicen bases de datos estructuradas para su almacenamiento, ya que
es mucho más rápido y eficiente en la recuperación y almacenamiento de
datos, sobre todo en las actividades de hacer correlación, filtrado y reportes
(Logging)90. (Chuvakin, 2013)
8.1.7.6 Aunque se encuentran varios métodos para el almacenamiento, en el
caso de un sistema de archivos de logs, este debe soportar la comprensión
que permite mejorar la seguridad y reducir notablemente el almacenamiento,
aunque existen otros formatos como basados en texto, binarios, archivos y
texto plano. Además es importante que soporte la rotación en los sistemas de
archivo de log, ya que como se menciono puede configurarse por tiempo o
tamaño dando flexibilidad a la hora de la consulta o análisis de logs, si el
88 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
89 Kent, K.
90 CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER.
96
sistema no lo soporta debería utilizarse aplicaciones de terceras partes91.
(Kent, 2006)
8.1.7.7 Es importante definir umbrales y alarmas para monitorear el estado
del almacenamiento en la infraestructura de la gestión de logs, esto por la
importancia de evitar el incumplimiento y perdida de registros, también
permite como medida de prevención definir las medidas a tomar de acuerdo
a las necesidades de la organización92, sin embargo en la implementación y
diseño de la infraestructura de gestión de logs debe estar bien definida. Por
eso se considera el tener un servidor alterno para copias de respaldo de los
archivos de logs y archivado de los mismos, para retención de los logs en
tiempos largos, definidos en las políticas con base en requerimientos de
cumplimiento en caso que una organización aplique.
(Chuvakin, 2013)
8.1.7.8 Una característica a tener en cuenta es el archivado de log, que es el
almacenamiento de los archivos de log en tiempos largos para su retención,
hay diferentes métodos y tecnologías, pero cada una cambia la forma y los
tiempos de recuperación de la información, Se deben tener en consideración
que entre mayor el tiempo de recuperación o el tiempo de almacenamiento
los costos son mayores93. En el anexo G se mencionan algunas de estas
tecnologías. (Chuvakin, 2013)
Análisis automático y correlación. En el desarrollo de la guía y en si en la implementación
de una herramienta SIEM, se hace necesario el análisis automático de los registros. En
este proceso, se puede definir como el paso más importante, la correlación de los
eventos.
La correlación tiene como objetivo encontrar coincidencias o relaciones entre uno o varios registros de una misma fuente o diferentes fuentes. La correlación ayuda
91 Karen Kent.
92 CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER.
93 CHUVAKIN, DR Anton A.
97
para realizar un análisis eficiente al momento de determinar un ataque o brecha de seguridad. La correlación desarrolla algunos procedimientos previos a realizar para mejorar el análisis de los registros.
El Filtro de eventos: consiste en eliminar registros duplicados, combinar eventos similares en un solo evento y en comprimir registros, para realizar un análisis rápido y efectivo.
Normalización: Consiste en cambiar los formatos de los datos en un formato común, para los eventos que llegan al SIEM.
98
8.1.7.9 Es importante que al momento de la definición, se debe tener acceso
a la descripción de los campos, del activo o de los activos que generan los logs al
SIEM, para identificar a cuales es posible realizar la normalización.
8.1.7.10 Uno de los principales retos que se identifican al momento de
atender un incidente de seguridad es el tiempo para identificar y reaccionar
ante un ataque, un análisis a nivel de infraestructura proporciona los
mecanismos necesarios para dar respuesta en menor tiempo y disminuir el
impacto de los incidentes de seguridad generados94. (Kent, 2006)
8.1.7.11 Definir y documentar los campos normalizados (tipo, estructura y
formato), teniendo en cuenta una futura implementación de un activo que genere
registros para ser monitoreados por el SIEM.
8.1.7.12 Las organizaciones deben evaluar si es necesario realizar la
normalización de los campos, teniendo en cuenta que este proceso puede
consumir un alto porcentaje de recursos de la máquina que realiza el
proceso95. (Kent, 2006)
Seguridad de los registros de logs. Aunque las herramientas SIEM, están diseñadas para
prevenir e identificar incidencias de seguridad que afecten a los activos de una
organización, estas no están exentas de ser atacadas o vulneradas, durante los procesos
en los que están involucrados.
Por lo anterior se deben controlar y evaluar los posibles riesgos que se presenten
en los procesos de almacenamiento, transmisión entre el activo generador, el
servidor de la herramienta SIEM y el procesamiento de registros.
94 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
95 Kent, K.
99
8.1.7.13 Dentro de las organizaciones se deben definir perfiles para aquellos
funcionarios que requieran acceder a los archivos de registros, de acuerdo a la
información requerida y la utilización de la información.
8.1.7.14 Evitar que el registro de log contenga información clasificada como
confidencial o sensible (como contraseñas), de acuerdo a las políticas o normas
de la organización.
8.1.7.15 La información almacenada en el SIEM (base de datos o en disco),
debe cumplir con encriptación fuerte y en general con los estándares
internacionales o nacionales que le apliquen a la organización96. (Kent, 2006)
8.1.7.16 Certificar que los desarrollos requeridos para el envío, recepción,
análisis y almacenamiento no incumplan con los lineamientos de seguridad
respecto a la integridad, disponibilidad y confiabilidad de la información de los
registros.
8.1.7.17 Todo cambio, consulta y eliminación sobre los registros de logs en el
SIEM deben estar monitoreados y auditados97. (Kent, 2006)
Notificación de alertas. De acuerdo a la política y los procedimientos que se crearon
anteriormente, teniendo en cuenta los pasos descritos en la presente guía, se deben
desarrollar y parametrizar las reglas de análisis de eventos y las notificaciones de alertas
a los eventos que no cumplan con los parámetros establecidos.
Es por esto que uno de los pasos principales indicados en la guía es el desarrollo
y planteamiento de la política de seguridad dado que lo que incumpla con la
misma es de obligatoria notificación.
96 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology.
97 Karen Kent.
100
Análisis de reportes. Un paso importante en la administración y gestión de logs, es el
análisis de los reportes, estos se convierten en un apoyo y recurso para el área de
seguridad en la lucha de mitigar riesgos y reducir vulnerabilidades.
Es necesario que en las organizaciones se definan y establezcan tareas operativas, de
acuerdo a la misión y visión de la organización cumpliendo con los objetivos propuestos
en la política de seguridad, para realizar un análisis correcto y efectivo de los reportes de
registros.
8.1.7.18 En la presente guía se sugiere que se realicen tareas con diferentes periodicidades98:
Diarias: para identificar posibles cambios en estructuras de los registros en los últimos días, tomar acciones en un menor tiempo.
Semanal: Se sugieren realizar revisiones semanales para evaluar posibles cambios y revisar variaciones en los sistemas.
Quincenales: Evaluar resultados de investigaciones realizadas.
Mensuales: Se recomiendan para evaluar procedimientos y estructuras de registros.
Anuales. Se sugieren para evaluar la efectividad y ajustes de la política de seguridad. (Chuvakin, 2013)
Mitigación de incidentes. Durante el análisis de los registros de logs, es posible identificar
eventos de importancia como incidentes o problemas operacionales que requieran de una
respuesta. Cada organización define el procedimiento para tratar estos eventos,
desarrollando políticas o aplicando estándares como ITIL.
8.1.7.19 Dentro de las mejores prácticas se recomienda construir una base de conocimientos de incidentes de seguridad, con información de vulnerabilidades conocidas, el significado de los mensajes de registro y datos que ayuden a identificar los incidentes que se estén generando99. (Chuvakin, 2013)
8.1.7.20 Cada persona tiene conocimientos y competencias distintas, y los
incidentes de seguridad tienden a involucrar distintos activos de la organización,
es por efectividad al solucionar estos incidentes que las organizaciones deben
98-99 CHUVAKIN, DR Anton A.; SCHMIDT, Kevin J.y PHILLIPS Chrispher. Logging
AND Log Management The Surrounding Logging and Log Management. Waltham:
Elsevier, 2013
101
armar grupos de trabajo, para realizar un análisis completo a los incidentes
presentados.
Eliminación de logs. Dentro del proceso de gestión de logs, es importante generar
políticas para archivar y eliminar los registros, teniendo en cuenta los procedimientos
establecidos por la organización.
9.1.11.1 Sobrescribir los registros con mayor tiempo de antigüedad, este
proceso es viable cuando se utilizan registros de control o complementos y no son
registros vitales para las investigaciones o para realizar los análisis de los
incidentes generados100.
9.1.11.2 Generar alertas de capacidad sobre la capacidad de la base de datos
o de los discos y evitar que se pierdan registros o eventos por inconvenientes en el
sistema de SIEM.
9.1.11.3 Los administradores de seguridad son los responsables de generar
las políticas para el almacenamiento de los registros por el tiempo adecuado y
generar los procedimientos de eliminación segura de acuerdo a las normas
establecidas.
102