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 1 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 2 3 TABLA DE CONTENIDO pág. TABLA DE CONTENIDO .......................................................................................................................... 4 INTRODUCCIÓN ....................................................................................................................................... 9 GENERALIDADES DEL TRABAJO DE GRADO .......................................................... 10 1. 1.1 1.2 1.3 1.4 MARCOS DE REFERENCIA ............................................................................................ 14 2. 2.1 2.2 2.3 MARCO CONCEPTUAL ......................................................................................................... 14 MARCO TEÓRICO........................................................................................................................ 16 MARCO LEGAL ....................................................................................................................... 18 METODOLOGÍA ................................................................................................................ 19 3. 3.1 FASES DEL TRABAJO DE GRADO ..................................................................................... 19 SELECCIÓN MODELO DE MEJORES PRACTICAS DE GESTIÓN DE LOGS ......... 21 4. 4.1 4.2 4.3 4.4 4.5 4.6 TECNOLOGÍA, PROCEDIMIENTOS Y POLÍTICAS PARA EL REGISTRO DEL LOG . 23 CAPTURA Y GENERACIÓN DE LOGS ............................................................................... 24 ALMACENAMIENTO Y RETENCIÓN DE LOGS ................................................................ 25 ANÁLISIS DE LOGS ............................................................................................................... 27 SEGURIDAD Y PROTECCIÓN DE LOGS ........................................................................... 28 MODELO BUENAS PRACTICAS GESTIÓN DE LOGS .................................................... 29 SELECCIÓN DE HERRAMIENTA SIEM LIBRE ............................................................ 31 5. 5.1 5.2 6. LÍNEA DE INVESTIGACIÓN........................................................................................................... 10 PLANTEAMIENTO DEL PROBLEMA .............................................................................................. 10 1.2.1 Antecedentes del problema ......................................................................................... 10 JUSTIFICACIÓN ........................................................................................................................... 12 OBJETIVOS ................................................................................................................................. 13 1.4.1 Objetivo general.......................................................................................................... 13 DESCRIPCIÓN DE HERRAMIENTAS SIEM ...................................................................... 31 5.1.2 OSSEC ........................................................................................................................ 33 5.1.3 OSSIM ........................................................................................................................ 34 5.1.4 GRAYLOG. ................................................................................................................. 34 COMPARATIVO HERRAMIENTAS SIEM ........................................................................... 36 ESTRUCTURA DE LA GUÍA METODOLÓGICA ........................................................... 38 6.1.1 6.1.3 6.1.4 6.1.5 6.1.6 Definición del alcance ................................................................................................ 39 Infraestructura gestión de Logs. ................................................................................ 41 Generación y transmisión .......................................................................................... 44 Retención y almacenamiento de logs ......................................................................... 45 Análisis automático y correlación.............................................................................. 47 4 6.1.7 6.1.8 6.1.9 6.1.11 DEFINICIÓN E IMPLEMENTACIÓN DE CASO DE PRUEBA ...................................... 52 7 7.1 7.2 7.3 8. Seguridad de los registros de logs .............................................................................. 48 Notificación de alertas................................................................................................ 49 Análisis de reportes .................................................................................................... 49 Eliminación de logs .................................................................................................... 51 DEFINICIÓN E IMPLEMENTACIÓN DE CASO DE PRUEBA.............................................................. 52 DESCRIPCIÓN DEL AMBIENTE..................................................................................................... 53 DESARROLLO CASO DE PRUEBA ................................................................................................ 55 7.3.1 Configuración y funcionamiento OSSIM. ................................................................ 55 CONCLUSIONES .............................................................................................................. 58 FIGURAS……………………………………………………………………………………………6 CUADROS…………………………………………………………………………………………..7 ANEXOS…………………………………………………………………………………………….8 5 FIGURAS FIGURA 1..…..……………………………………………………………………………..36 FIGURA 2........……………………………………………………………………………..54 6 CUADROS CUADRO 1…..……………………………………………………………………………..36 CUADRO 2......……………………………………………………………………………..54 CUADRO 3..………………………………………………………………………………..54 CUADRO 4..………………………………………………………………………………..56 7 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 8 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. 9 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 1.2.1 PLANTEAMIENTO DEL PROBLEMA 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. 10 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? 11 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. 12 1.4 1.4.1 OBJETIVOS 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. 13 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ío 3. (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 3 Task, J. (25 de Abril de 2015). National Instituto of Standars and Tecnology. CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER. 14 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 5 Chris, L. (24 de 10 de 2015). Cisco Systems The BSD Syslog Protocol. Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 15 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. 16 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 7 Task, J. (25 de Abril de 2015). National Instituto of Standars and Tecnology. Task, J. (25 de Abril de 2015). National Instituto of Standars and Tecnology. 17 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 9 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. Securosis. (25 de 8 de 2010). Securosis. 18 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 19 ayude a su entendimiento y funcionalidad con el proceso de implementación en un caso de prueba. 20 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 . 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. 11 21 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. Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision. 16 Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision. 15 22 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 23 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: 17 18 Accesos de usuario. Acceso privilegiado o administrativo. Uso de mecanismos de autenticación e identificación. Accesos remotos e inalámbricos Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision. Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision. 24 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 20 EMC-RSA Envision. Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision. 25 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. 26 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. 27 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 24 Envision, E.-R. (9 de 5 de 2007). EMC-RSA Envision. EMC-RSA Envision. 28 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. 29 Figura1. Modelo de Gestión de Logs Fuente: Autor 30 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 31 diseñada para infraestructuras investigaciones académicas. pequeñas, sistemas no críticos y para 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: 25 ¿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) PRELUDE. (16 de 8 de 2015). 32 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. 33 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 red 27. (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. 34 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 35 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 Descubrimien to de Activos CARACTERISTI CAS OSSIM LOGALYZE X Gestión Centralizada Recolección de Logs y eventos de seguridad X X X X X X X X X X Correlación de Eventos X X X Análisis de Logs Clasificación y Prioridad de eventos X X X X X X Monitoreo en tiempo Real X X X X X Normalizació n X X X X X X X X X X X X X X X Agente/Sin Agente Agente/Sin Agente Agente/Sin Agente Agente Agente/Sin Agente X X X X X X X X X Reportes Interfaz Gráfica de administració n Modo de recolección de Eventos LINUX/UNIX S.O. SOPORTADO GRAYLOG MAC X BSD 36 X X X X X X X X WINDOWS 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. 37 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 38 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 31 CHUVAKIN, D. A., & SCHMIDT, K. J. Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 39 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 33 CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER. Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 40 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. Kent, K. 36 Kent, K. 35 41 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. 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. 38 42 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. Kent, K. 43 Kent, K. 44 Kent, K. 45 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 42 43 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. Kent, K. 48 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 49 Kent, K. 47 44 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. 45 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. 46 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 mayores 56. 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, 56 2013. CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER. 47 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. Kent, K. 58 -59 48 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ón 59. (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 60 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. Kent, K. 49 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. 50 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 registros. Eliminar los logs de manera que no haya trazabilidad de estos 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 63 Karen Kentrugiah, 2006. Karen Kent. 51 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. 52 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 53 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 54 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. 55 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 Captura de pantalla 1 2 3 4 5 CANTIDAD REGISTROS EN LA FUENTE REGISTROS EN EL SIEM EFECTIVIDAD (%) # de Pruebas # Registros generados por la fuente # Registros capturados SIEM # Registros fuente/# Registros capturados SIEM 5 5 5 100% Acceso denegado Se realiza intento de ingreso a servicio no permitido de escritorio remoto Acceso permitido Se realiza ingreso a página Web permitida 5 5 5 100% 5 5 5 100% Windows Reinicio de Se reinicia servicio por servicio IIS modificación 5 5 5 100% Router Se realiza cambio de Cambio de configuración configuración en Router 5 50 50 100% Firewall Se realiza ataque con de herramienta DoS GENERADOR Fuente de Logs Firewall Router PRUEBAS DESCRIPCIÓN Nombre de la Prueba (Acceso, Descripción de Modificación, la prueba Cambio) Correlación eventos Fuente: Autor 56 En el Anexo J se muestran las evidencias de la transmisión y captura de logs para cada uno de los casos de prueba. 57 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. 58 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. 59 BIBLIOGRAFIA Alertlogic. (10 de 5 de 2015). Alertlogic. Obtenido de Alertlogic: http://www.alertlogic.com/wp-content/uploads/2012/01/Log-ManagementBest-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_Man agement.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-logmanagement/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). http://docs.graylog.org/en/latest/ Graylog. Obtenido de Ipswitch. (9 de 5 de 2015). Ipswitch . Obtenido de http://www.enterprisemanagement360.com/wpcontent/files_mf/white_paper/elm_whitepaper_9-30-10.pdf Graylog: Ipswitch : 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/1documentation/12-logalyze-installation-manual 60 OSSEC. (16 de 8 de 2015). OSSEC. http://www.ossec.net/?page_id=165 Obtenido de OSSEC: PRELUDE. (16 de 8 de 2015). PRELUDE. Obtenido de PRELUDE: http://www.prelude-siem.com/index.php/uk/products/87-products/97-preludepresentation-uk Securosis. (25 de 8 de 2010). Securosis. Obtenido de Securosis: https://securosis.com/assets/library/reports/Securosis_Understanding_Selec ting_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/eighthannual-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-logmanagement-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 61 ANEXO A. COSTO DE PLATAFORMA SIEM DE ALLIENVAULT Se relaciona el costo de implementación de la plataforma SIEM de AllienVault. 62 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. 63 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. 64 Sistemas de Prevención de Intrusos (IPS) Servidores de correo Servidores Proxy Servidores de Aplicación Aplicaciones Firewalls de Aplicación 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. 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 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 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 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 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. 65 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 Lider de TI Administradores de red y de servidores Administrador de seguridad Equipos de respuesta a incidentes Desarrolladores de aplicaciones Auditores RESPONSABILIDAD 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. 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 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. 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 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. Encargados para el uso de datos dentro de los logs para evidencia en auditorias para cumplimiento y procesos desarrollados en la organización. 66 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 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 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. 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 cambios Autenticación y Autorización Acceso al sistema y la información 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. 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 Rendimiento y Gestión de Capacidad Continuidad de Negocio y Gastion de Disponibilidad Miscelania de errores y fallas Miscelania de mensajes de depuración 67 Los sistemas registran cuando es apagado o reiniciado, y otros mensajes realitivos a continuidad como backups, redundancia o utilización. 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. 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. CATEGORIAS DESCRIPCIÓN Son mensajes diseñados para permitir conocer que algo a ha ocurrido, algo Informational normal, descartando algun tema de seguridad. Debug Warning Error Alert 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 Son mensajes concerniente a situaciones donde se han perdido algo del sistema pero no impacta la operación. 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. 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 68 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. 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. 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. Los sistemas de procesamientos de logs deben garantizar exactitud en sus SINCRONIZACIÓN DEL registros para disponer de medidas fiables en los registros de todos los sistemas TIEMPO 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 LOGS Se deben retener los log de acuerdo a la ley HIPPA, la cual la organización tiene el deber de cumplir. El área de TI debe respaldar el almacenamiento de logs mediante tecnologías ALMACENAMIENTO DE confiables y eficientes asegurando la disponibilidad de los logs, se debe asegurar LOGS 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. Se debe asegurar la confidencialidad, integridad autenticidad de los logs a través SEGURIDAD DE LOGS de su ciclo de vida, con los controles adecuados con el fin de evitar algún fraude informático. Es necesario que se cuente con un sistema de monitoreo de los registros que MONITOREO genere alertas en caso de una situación inusual. Se debe contar con métodos y herramientas efectivas para la eliminación de ELIMINACIÓN registros sin comprometer la fuga de información y que no quede traza alguna de los logs. 69 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 Son unidades degran capacidad y normalmente seencuentran internos dentro de un mismo equipo de computo, esta formados por varios discos apilados Puede tener un tiempo largo, es economico pero sobre los que leen y escriben información a traves de una cabeza magnetica, al compartir recursos con otros servicios de estos almacenan datos para ser accedidos de forma inmediata y automatica Discos Duro - Unidad de Disco Rigido computo tiene un riesgo amplio de perdida y pero aun tiene limitaciones en velocidad, pero por estar en dentro falla, ademas la recuperacion de los datos es internamente dentro de un dispositivo tiene gran riesgo de falla, Los Discos rapida y automatica rigidos externos tampoco se consolidan como fiables para respaldos de empresas por su fabricación y sus unidades mecanicas. Son unidades externas dealmacenamiento quenecesitan un lector optico para Tienen un tiempo de vida corto, hay discos con Unidad de Disco Optico CD, DVD y Blueray leer o escribir en las pistas del disco, las diferentes tecnologias cambian en gran almacenamiento, es portable, economico capacidad (CD, DVD, Bluray) pero no es eficiente para recuperar datos Limitado almacenamiento, en algunos casos es Se basan en una tecnologia de memoria no volatil, hecho con componentes costoso,la transmision es rapido sin embargo la Unidad de Estado Solido (USB, Flash) electronicos, con velocidades de transmisión altas. recuperación es igual al dedisco opticos manual y con untiempo mas largo. Cintas Magneticas Es especial para realizar backups y retener por tiempos largos, no es costoso y tienen tiempo de Son degran capacidad, tienesu uso para copias derespaldo, las tecnologias y vida moderado, algunas caracteristicas de formatos cambian su capacidad de velocidad de transmisión y velocidad de transmisión es aceptable para los almacenameinto, algunos son DAT, DDS, DLT y LTO sistemas, no es automatico para la recuperación por que debe ser con intervención humana. ALMACENAMIENTO SAN Es posible configurar una arquitectura, que es Es una arquitectura completa para el almacenamiento con diferentes muy eficiente para la recuperación y control componentes desde switches e alta velocidad y sistemas con discos duros sobre el almaenamiento ademas se puede ir rigidos o de estado solido actualizando periodicamente evitando perdidas sin embargo es un escenario muy costoso. 70 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. 71 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. 72 73 Graficas que indica la tendencia de los logs, de acuerdo a los tipos y fuentes. 74 Lista general de Eventos Capturados por el OSSIM 75 ANEXO J. EVIDENCIA CAPTURA DE PANTALLA PARA LOGS GENERADOS 1. Captura de logs prueba acceso denegado 76 77 2. Captura de logs acceso permitido 78 3. Captura logs reinicio de servicio por modificación 79 80 4. Captura de logs por cambio en configuración de interfaz de red 81 82 5. Captura logs correlación por detección de ataque denegación de servicio 83 84 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. 85 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. 86 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ón 66. 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 65 CHUVAKIN, D. A., & SCHMIDT, K. J. (5 de 10 de 2013). ELSEVIER. 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. 87 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 68 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. 88 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. 89 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. 90 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. 91 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. 92 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.11Que 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. 93 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. 94 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. 95 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. 96 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. 97 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.10Uno 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.12Las 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 95 Kent, K. (25 de 4 de 2006). National Institute of Standars and Technology. Kent, K. 98 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.15La 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. 99 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.18En 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 100 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. 101 102