Mostrando entradas con la etiqueta SIEM. Mostrar todas las entradas
Mostrando entradas con la etiqueta SIEM. Mostrar todas las entradas

viernes, 19 de diciembre de 2014

[Algunos] Retos de un CISO en el mundo actual

La vida del CISO (Chief Information Security Officer) o responsable de Seguridad de la Información antes de que nos invadieran las siglas anglosajonas, es una vida realmente dura. Entre sus responsabilidades se encuentran prever y proteger a la organización de todos los riesgos que puedan afectar a la seguridad de sus activos de información, detectar y responder de manera adecuada ante los incidentes de seguridad, gestionar la infraestructura de seguridad de su organización, gestionar todo el ciclo de vida de las vulnerabilidades técnicas y garantizar el cumplimiento con las leyes, regulaciones y estándares pertinentes en materia de seguridad de la información.

Pero si todo esto no os parece un reto suficientemente complicado, hay que añadir que el CISO tiene que afrontarlo con presupuestos generalmente muy ajustados o por debajo de lo necesario debido a lo difícil que es predecir el ROI de las inversiones en seguridad. Y no sólo es difícil predecirlo, sino que en muchos casos también es harto complicado medirlo una vez la inversión se ha realizado. Y es que aquí nos encontramos con la llamada ‘paradoja de la seguridad’ y que se da cuando en una organización no se están produciendo incidentes de seguridad. Cuando esto ocurre, la dirección de la empresa puede dudar si la falta de incidentes se debe a la inversión realizada o si seguirían sin tener incidentes aunque redujeran el presupuesto dedicado a seguridad. Y este tipo de dudas, en los tiempos de crisis que vivimos, ya sabemos cómo suelen acabar.

En mi opinión, la mejor manera que tiene un CISO de justificar sus presupuestos es realizar un análisis de riesgos presentando el ROI de la inversión de seguridad en forma de reducción del riesgo. Sin embargo, el resultado de estos análisis de riesgos se debe presentar en el idioma que la dirección entiende: $$. Hay que poner un valor cuantitativo y económico a cada riesgo, justificándolo adecuadamente y teniendo en cuenta el contexto del negocio. Y este es otro punto realmente complicado, ya que en muchas ocasiones el CISO no dispone de la información y el conocimiento del contexto de negocio para poder trasladar correctamente los riesgos de seguridad a impactos económicos para el negocio. Y esto nos lleva a una nueva paradoja del mundo de los CISO; les sobran los datos pero les falta información. Y es que el exceso de datos es otro de los mayores problemas con los que tiene que lidiar un CISO (o su equipo); eventos generados por multitud de dispositivos de seguridad y sistemas, resultados de escaneos de vulnerabilidad y pruebas de penetración, nuevas vulnerabilidades, nuevas amenazas, nuevas técnicas y tecnologías aparecidas en el ámbito de la seguridad de la información, etc...

Ser capaces de lidiar con toda esta cantidad de datos y ser capaces de transformarla en información útil, es uno de los grandes desafíos a los que se enfrentan los departamentos de seguridad de la inforamción. Ser capaces de centralizar, correlacionar y analizar a tiempo la información es un primer paso sin duda importante para ser capaces de convertir los datos en información. Generar alertas que permitan reaccionar a tiempo ante incidentes de seguridad, o análisis de tendencias que permitan detectar anomalías va un paso más allá y permite convertir esa información en inteligencia de seguridad. Pero el auténtico reto para el CISO es dar aún un paso adicional y ser capaz de transformar esa información y esa inteligencia de seguridad en inteligencia de negocio, siendo capaz de relacionar de una manera rápida y acertada esos riesgos e incidentes de seguridad con el impacto real que tenga para el negocio. Es decir, el auténtico desafío que deben encarar ahora los responsables de seguridad de la información es el de ser capaces de reportar en tiempo real a su dirección cual es el riesgo para el negocio que se está derivando de los riesgos de seguridad de la información, de manera que la dirección pueda contar con información actualizada e integral de los riesgos que afectan a su organización, independientemente de su origen (financieros, de seguridad física o de la información, de cumplimiento, de evolución de los mercados, de evolución de la competencia, etc..). Una vez los CISO puedan contar con herramientas que les permitan realizar esa transformación de datos a inteligencia de negocio de una manera eficiente, su vida será un poco más sencilla puesto que la justificación de sus presupuestos caerá por su propio peso. O visto desde la otra perspectiva, la Dirección del negocio contará con la información suficiente a la hora de tomar decisiones sobre qué objetivos concretos de seguridad exigirán al departamento de seguridad de la organización y, por lo tanto, que partida presupuestaria le asignarán para el cumplimiento de esos objetivos.





Así pues, en resumen, un buen CISO debe disponer de un correcto equilibrio entre habilidades técnicas y habilidades de gestión y conocimiento del negocio, teniendo capacidad para lidiar tanto con el personal técnico como con la dirección de la compañía mientras mantiene bajo su paraguas un alcance realmente amplio de responsabilidades en este apasionante mundo de la seguridad de la información dónde lo que ocurre hoy nada tiene que ver con lo que estará pasando el año que viene, o lo que es prácticamente lo mismo, de aquí a dos semanas. J

jueves, 13 de febrero de 2014

Plan de Respuesta ante Incidentes de Seguridad & PCI DSS

No hay organización que esté a salvo de sufrir un incidente de seguridad.  Se puede tardar más o menos en padecerlo y en resolverlo, ser más o menos grave, o incluso puedes no enterarte de que estás teniendo un incidente de seguridad (no, tranquilos, no voy a hablar de APTs), pero en algún momento tu organización necesitará reaccionar ante un incidente.

Por ello, toda organización debería contar con un plan de respuesta ante incidentes de seguridad coherente con el impacto potencial que un incidente de seguridad pueda llegar a suponer para su negocio. La ausencia de un plan de respuesta ante incidentes de seguridad puede incrementar considerablemente el tiempo de reacción ante un incidente e incluso puede provocar que la respuesta no sea la adecuada y acabar agravando el impacto del mismo.

El apartado 12.10 de PCI DSS v3 requiere a las organizaciones afectadas por el estándar que implementen un plan de respuesta de este tipo y que estén preparadas para responder de inmediato ante cualquier compromiso en sus sistemas. En este sentido, lo que exije el estándar es que el plan de respuesta incluya en su alcance todos los elementos claves que son necesarios para que la organización responda de manera efectiva en caso de que el compromiso pueda afectar a los datos de titulares de tarjeta. Sin embargo, puestos a desarrollar un plan de respuesta, pienso que es ridículo ceñirse únicamente al ámbito de PCI DSS, ya que con poco más esfuerzo podemos contar con un Plan de Respuesta que alcance a toda la organización y que nos permitirá responder de una manera eficaz y eficiente en caso de que se produzca un incidente.

Veamos pues las pautas a seguir para desarrollar un Plan que nos permita cumplir con el requisito 12.10 de PCI DSS pero que a su vez nos prepare para actuar ante incidentes que afecten a otros ámbitos de nuestra organización.

Preparación


En la fase de preparación deberemos llevar a cabo las siguientes actividades principales:

1- Tener claro el alcance de nuestro Plan. No es lo mismo preparar un Plan ante Incidentes de Seguridad que acotar el alcance únicamente a incidentes de Seguridad de la Información, de seguridad laboral, de seguridad patrimonial, etc... Para cumplir con PCI DSS, el alcance del Plan debe incluir como mínimo, todos los sistemas críticos dentro del ámbito de procesado, almacenaje y transferencia de datos de titulares de tarjeta.

2- Se deben definir y documentar los roles y las responsabilidades de todos los participantes en el Plan de Respuesta ante Incidentes.

3- Aunque numerosas metodologías de gestión de incidentes de seguridad proponen la realización de un análisis de riesgos, incluido el recien publicado marco de ciberseguridad del NIST, yo soy partidario de realizar únicamente un BIA (Business Impact Analisys) que nos permita tener claro qué impacto puede tener un inciente en diferentes ámbitos (legal, financerio, operativo, daños humanos, reputación). Hay diferentes metodologías o aproximaciones para realizar un BIA pero mi recomendación, sobretodo en una primera implantación del Plan, es optar por una que sea suficientemente simple como para tener un BIA realista en poco espacio de tiempo. Es importante señalar que este BIA no debe limitarse a analizar incidentes que dañen la disponibilidad de la información, puesto que no se trata de preparar el Plan de Continuidad de Negocio, si no que se tiene que tener en cuenta también los impactos en cuanto a pérdida de confidencialidad e integridad de la información, así como otros tipos de incidentes no relacionados con la seguridad de la información en caso de que el alcance del Plan sea tal.

4- Definir que escenarios de incidentes se pueden producir partiendo del análisis realizado en el BIA. Es decir, documentar todos aquellos sucesos que puedan causar los principales impactos identificados en el punto anterior. Es recomendable en una primera redacción del Plan no ser excesivamente ambicioso y agrupar e unificar la respuesta ante incidentes de manera que el volumen de escenarios sea manejable. No nos servirá de nada documentar 500 posibles casuísticas si luego vamos a tardar 5 años en redactar los procedimientos de respuesta para cada una de ellas.

5- Documentar los mecanismos establecidos para poder detectar la materialización de los escenarios definidos en la fase anterior. En esta fase es muy probable que se identifiquen deficiencias o imposibilidades en la detección de algunos de los escenarios. En aquellos casos en los que sea viable, se debe preparar un plan de mejora destinado a implantar controles o mejoras que permitan la detección en un tiempo tolerable de dichos escenarios. Al considerar los elementos que pueden disparar el procedimiento de gestión de incidentes, PCI DSS obliga a que como mínimo se consideren los sistemas de monitorización de la organización, como son los IDS/IPS, los firewalls o los sistemas de monitorización de la integridad de los ficheros (FIM).

6- Documentar los criterios de clasificación de los incidentes. Se debe definir una taxonomía y los criterios para clasificar un potencial incidente en su correspondiente categoría. Nuevamente, mi recomendación es que prime la simplicidad no definiendo más de 10 categorías diferentes de incidentes para facilitar su clasificación.

7- Documentar los procedimientos de actuación en caso de materialización de cada tipo de incidente. Los procedimientos deben incluir el detalle de acciones a realizar para:
* Contener el incidente.
* Solventar el incidente.
* Recuperar la operativa normal.
Entre estos procedimientos, se deberán incluir o referenciar los procedimientos del Plan de Continuidad de Negocio que deban ser seguidos en caso de que el incidente afecte a la continuidad del mismo.
Adicionalmente, para cumplir con PCI DSS, se deberán incluir o referenciar los procedimientos de copias de respaldo de los datos y cualquier aspecto o requisito legal a considerar en caso de incidente.

8- Documentar las estrategias y procedimientos de comunicación ante un incidente de seguridad. Es decir, qué se debe decir, a quién se debe decir y cómo se debe decir en cada caso, o en todo caso, definir claramente quien es el responsable de tomar estas decisiones en caso de incidente. El daño a la imagen o la reputación de la compañía puede variar enormemente en función de qué se comunique y cómo se comunique a raíz de un incidente de Seguridad. Para cumplir con PCI DSS estas estrategias deberán incluir, como mínimo, el procedimiento a seguir para comunicar cualquier compromiso de datos de tarjeta a las marcas de tarjeta de pago.

9- El Plan debe ser comunicado y distribuido entre todos los afectados y se debe garantizar su disponibilidad durante un potencial incidente. Es decir, si uno de nuestros escenarios posibles es que por motivo de un DoS se nos caigan nuestros sistemas corporativos, no guardemos únicamente en ellos nuestro Plan de Respuesta ante Incidentes, puesto que no podremos recuperarlo cuando lo necesitemos. Así mismo, si uno de los escenarios contemplados es el no poder acceder a la oficina, tampoco nos serviría de nada tenerlo impreso en nuestro escritorio.

10- Se deben definir y establecer las vías necesarias para que cualquiera pueda notificar a los responsables la ocurrencia de un posible incidente. Estas vías deben ser sencillas, rápidas y contar con diversas alternativas por si una de ellas fallara.

11- El equipo de respuesta ante incidentes debe estar convenientemente entrenado y con una disponibilidad de 24x7 para actuar en caso de que se materialice un incidente para evitar que el retraso en su resolución pueda agravar su impacto y consecuencias. Por otro lado, la correcta procedimentación de la actuación y formación del equipo son vitales para impedir que las actividades realizadas para solventar el incidente puedan degradar o corromper las evidencias necesarias para la adecuada investigación forense del incidente.

12- Se debe planificar un plan de pruebas que permita tener un alto grado de seguridad de que el Plan propuesto funciona correctamente en caso de incidente. Las pruebas, que deberán realizarse como mínimo anualmente, son críticas para garantizar que los procedimientos definidos son realmente eficaces y que todo el personal afectado tiene conocimiento necesario de los mismos. En este sentido, será necesario probar únicamente aquellas tipologías de incidentes que no se hayan dado realmente durante el año, no siendo necesario probar los procedimientos que se hayan usado realmente durante el año, al no ser que se hayan sido mejorados o modificados.

Durante el incidente.


Durante el incidente se deben tener en cuenta los siguientes aspectos:

1- Se deben seguir los procedimientos definidos en el Plan en cada caso.
2- Se debe mantener una bitácora detallada con todos los sucesos y actuaciones llevados a cabo durante el incidente.
3- Se debe priorizar la contención del incidente.
4- Una vez contenido, se debe proceder a su resolución.
5- Finalmente, una vez resuelto, se debe proceder a la recuperación de los sistemas afectados.

Mejora continua:

PCI DSS, y cualquier metodología de gestión de incidentes de seguridad que se precie, exige que se incluya un apartado específico de mejora continua en el plan de respuesta ante incidentes de manera que se analice la actuación y resolución ante cada incidente de seguridad para detectar áreas de mejora en los procesos de detección o respuesta ante los incidentes.

Para ello, se deben analizar los outputs, entendiendo qué ha pasado y por qué ha pasado, para cada uno de los incidentes sufridos así como de las pruebas realizadas y analizar qué mejoras se pueden implementar en el Plan en diversos ámbitos:

* Mejoras en la prevención de los incidentes.
* Mejoras en la detección de los incidentes.
* Mejoras en la contención y resolución de los incidentes.
* Mejoras en la recuperación de los equipos o del negocio.
* Mejoras en el plan de pruebas.
* Mejoras en los escenarios de incidentes definidos.
* Mejoras en la formación del personal.

Por último, también es importante tener en cuenta el plan dentro de la gestión del cambio de la organización, de manera que se actualice el Plan de Respuesta ante Incidentes siempre que algún cambio en los sistemas o la organización deje obsoleto algunos de los procedimientos definidos.



En definitiva, se trata de contar con un Plan documentado, distribuido, probado y conocido que permita actuar de la mejor manera y en el menor tiempo posible ante un incidente de seguridad con el objetivo de minimizar el impacto en diversos ámbitos que dichos incidentes pueden suponer para nuestras organizaciones.

miércoles, 26 de mayo de 2010

Gestión de Eventos de Seguridad

Todos somos conscientes de la creciente importancia que la información y su tratamiento está adquiriendo para las organizaciones. Esta importancia deriva del aumento exponencial del volumen de datos con el que han de lidiar los Responsables de Sistemas de Información. Las necesidades de almacenamiento y procesado de datos se siguen multiplicando, al igual que las necesidades de asegurar la información en términos de Confidencialidad, Integridad y Disponibilidad.

Actualmente, nos hayamos inmersos en un cambio de paradigma en el que la seguridad está pasando a tratarse como un proceso continuo totalmente integrada con el resto de procesos de las organizaciones. Para que este cambio se pueda llevar a cabo, es imprescindible que se implementen sistemas o plataformas que permitan analizar, comprender y reaccionar ante los eventos de seguridad que se produzcan en nuestra compañía.

Sin embargo, llevar a cabo estas tareas de análisis es realmente complejo, ya que el número de fuentes que pueden generar eventos de seguridad es cada vez mayor; Firewalls, IPS/IDS, VPN, Servidores Web, Logs de aplicaciones, Sistemas centrales, Sistemas distribuidos, PC de usuarios, portátiles, dispositivos móviles, cámaras de videovigilancia, registros de entrada física a los edificios, y un largo etcétera…

Por lo tanto, las organizaciones se enfrentan en la actualidad a volúmenes ingentes de eventos que no pueden ser controlados de una forma manual. Atrás quedaron los tiempos en los que bastaba con uno o varios operadores visualizando una consola de logs para controlar lo que ocurría en los sistemas de una instalación.
Por otro lado, muchos de estos eventos no tienen sentido por sí mismos, sino que han de contextualizarse con eventos provenientes de otras fuentes. Es decir, nuestro sistema de análisis ha de ser capaz de aplicar inteligencia y correlacionar eventos entre sí. Además es imprescindible realizarlo en tiempo real, ya que en la mayoría de los casos la velocidad de detección será clave para que podamos reaccionar a tiempo ante una amenaza o incidente grave de seguridad.

Son muchas las herramientas que se han desarrollado para ayudar a las organizaciones en este ámbito, y suelen agruparse bajo la denominación genérica de SIEM (Security Information Event Management). Sin embargo, nos encontramos con que las diferentes soluciones abordan la misma problemática desde múltiples perspectivas.

Así, podemos dividir las soluciones SIEM en dos grandes grupos: aquellas que consolidan todos los eventos de seguridad en una o varias bases de datos, y las que, por el contrario, guardan los eventos respetando el formato nativo de los mismos.

En el primer caso, el hecho de utilizar una base de datos, redunda en un mejor rendimiento a la hora de realizar consultas a posteriori, lo que se suele conocer como “análisis forense” de los datos. Además, facilita la correlación entre los diferentes eventos mediante el uso del motor de búsqueda de la propia base de datos. No obstante, la inserción de nuevos eventos y el mantenimiento del almacenaje pueden verse seriamente penalizados por el mismo motivo.

Por el contrario, las soluciones que no se apoyan en una base de datos para almacenar los eventos, sino que los guardan en su formato nativo, son capaces de manejar volúmenes de eventos muy superiores sin ver su rendimiento tan severamente afectado como en el caso anterior. Además, al no cambiar el formato de los datos, pueden tener mayor fuerza probatoria en caso de tener que ser presentados como evidencia electrónica llegado el caso.
Otro aspecto clave a tener en cuenta al realizar una comparativa de sistemas SIEM es su escalabilidad, ya que deberemos asegurarnos que la solución pueda crecer sin problemas al mismo ritmo que lo haga nuestra organización y sus Sistemas de Información.

Por último, cabe analizar las funciones adicionales que pueda presentar la solución, como pueden ser cuadros de mandos técnicos o de cumplimiento normativo, alertas o automatización de acciones y facilidad de implementación, uso y gestión de la plataforma.

La concienciación en lo que se refiere a temas de seguridad se va incrementando y consolidando en la sociedad y, poco a poco, es de esperar que se establezcan nuevos requisitos legales y normativos. Todo esto generará un aumento en la demanda de soluciones de calidad alineadas con los objetivos de negocio de las organizaciones.

En conclusión, para elegir un sistema SIEM (Security Information Event Management) idóneo, hay que tener en cuenta múltiples factores entre los que destacan el volumen de datos a tratar; la complejidad de nuestros sistemas de información; la identificación de los diferentes roles que utilizarán la aplicación o el uso concreto que se va hacer de la misma. Solamente teniendo en cuenta todas las variables implicadas podremos estar seguros de implementar con éxito la solución SIEM más adecuada y que ofrezca un mejor servicio a nuestra organización.