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.

1 comentario:

Edison dijo...

Excelente tu blog de PCI-DSS