ACTUALIZACIÓN: Esta entrada, publicada originalmente en February 12, 2021, se ha actualizado para reflejar la situación actual de PICERL, los marcos de ciberseguridad y el panorama de amenazas, que está cambiando drásticamente.
En el panorama de las amenazas digitales, en constante evolución, comprender y aplicar planes de respuesta ante incidentes (IR) resulta fundamental para cualquier organización que desee reforzar sus defensas de ciberseguridad y responder de manera eficaz ante los incidentes. Una de estas metodologías es PICERL, un marco de ciberseguridad que las organizaciones pueden adoptar para aumentar su capacidad de respuesta ante incidentes de seguridad en la actualidad y para reforzar sus defensas frente a incidentes que puedan producirse en el futuro.
La respuesta ante un incidente de ciberseguridad —ya sea una filtración de datos, un ataque de ransomware u otro tipo de ciberataque— puede afectar gravemente a las operaciones comerciales habituales de una organización.
Sin una respuesta eficaz ante los incidentes, estos pueden minar la confianza del público, erosionar el valor de la marca y suponer una importante merma en los ingresos brutos.
En este blog, analizamos todo lo relacionado con PICERL, incluida una breve historia de su origen; comparamos PICERL con otros modelos habituales de ciberseguridad; y ofrecemos perspectivas prácticas sobre la gestión de incidentes que pueden contribuir a que la implementación de un proceso como PICERL u otros marcos de seguridad « » sea un éxito en su organización.
¿Qué es el PICERL en el ámbito de la ciberseguridad?
PICERL es un proceso de respuesta ante incidentes que consta de seis pasos: « » (prevención), «» (preparación), « » (investigación), «» (identificación), « » (), « » (contención), «» (erradicación), « » (recuperación) y « » (lecciones aprendidas).
Creado por SANS, una organización privada fundada en 1989 con el objetivo de ofrecer investigación y formación en materia de seguridad, el modelo PICERL se ha convertido en un estándar del sector para la respuesta ante incidentes. Son muchos los que consideran que PICERL es un marco eficaz, ya que ofrece un enfoque estructurado y exhaustivo para gestionar los incidentes de seguridad.
Seguir el modelo PICERL garantiza que las organizaciones estén bien preparadas para hacer frente a los incidentes (Preparación), puedan identificarlos rápidamente (Identificación), contengan la amenaza para evitar daños mayores (Contención), eliminen la amenaza del sistema (Erradicación), se recuperen del incidente y vuelvan al funcionamiento normal (Recuperación) y aprendan de lo ocurrido para mejorar las respuestas futuras (Lecciones aprendidas).
Repasemos los pasos del método PICERL con mayor detalle, al tiempo que destacamos las conclusiones prácticas que puede aplicar hoy mismo para ayudarle a minimizar el impacto de los incidentes y reforzar la postura de seguridad general de su organización.
Paso 1. Prepárese
La preparación garantiza que participen las personas adecuadas de los equipos adecuados, que comprendan sus funciones y que sepan qué hacer cuando se produzca un incidente.
La fase de preparación debería dar lugar a un plan que permita a los miembros del equipo de respuesta ante incidentes realizar simulacros, del mismo modo que las organizaciones practican sus procedimientos de copia de seguridad y recuperación de datos (DR).
Los planes de respuesta ante incidentes deben ensayarse periódicamente para subsanar cualquier deficiencia. Los simulacros de respuesta ante incidentes (IR) proporcionan a los miembros del equipo la confianza necesaria para actuar con eficacia bajo la presión de un incidente real.
[Lea también: IA frente a humanos: Por qué SecOps podría (o no) ser el próximo campo de batalla]
Los equipos de relaciones con inversores que participen en simulacros deberían ser capaces de responder a preguntas como:
- ¿Quién se encarga de informar al equipo de relaciones públicas (RP)?
- ¿Quién se encarga de informar al departamento jurídico?
- ¿Quién se encarga de informar al departamento de finanzas?
- ¿En qué casos es necesario notificarlo a las fuerzas del orden o a los organismos reguladores?
La fase de preparación también determina si dispone de las herramientas adecuadas. De no ser así, ¿dispone de la financiación necesaria para adquirirlos y impartir formación a los miembros del equipo? Es importante que, una vez elaborado el plan de respuesta ante incidentes, la alta dirección lo revise y lo apruebe, incluyendo un presupuesto para su financiación.
Paso 2. Identificar
Una vez que haya determinado que se trata de un incidente, la fase de identificación es en la que comienza a realizar una clasificación inicial respondiendo a preguntas como:
- ¿Cuándo comenzó y cómo ocurrió?
- ¿Cuál fue el punto de entrada?
- ¿Se trataba de una vulnerabilidad sin parchear de ?
- ¿Quién lo encontró y cómo lo encontramos?
- ¿Conocemos el alcance? ¿Se limita a una o dos personas o activos, o es algo generalizado?
- ¿Podemos seguir haciendo negocios?
- ¿Afectarán las medidas que tomemos a alguna de nuestras líneas de negocio?
Con mucha frecuencia, las credenciales comprometidas constituyen el punto de entrada. A partir de ahí, el incidente se agrava y los atacantes aprovechan cualquier oportunidad que se les presente en su entorno.
Tanium utiliza un análisis en profundidad de sus terminales para investigar a fondo las amenazas
Para mejorar la eficacia a la hora de identificar amenazas, las organizaciones han comenzado a aplicar elementos de juego a la preparación y las pruebas de su proceso de respuesta. Por ejemplo, puede ofrecer premios al equipo que detecte el correo electrónico de phishing « » ( ) o que cumpla con su plan de lista de comprobación de la forma más rápida y clara. La gamificación resulta especialmente útil para los profesionales de la seguridad que se inician en el sector.
Paso 3. Contener
Una vez que se ha declarado un incidente, la contención consiste en ejecutar su plan para evitar que el comportamiento indeseado se propague. Existen dos corrientes de pensamiento muy extendidas sobre las metodologías de contención, cada una de las cuales presenta ventajas e inconvenientes:
Una estrategia de contención a corto plazo podría consistir simplemente en emitir una orden de cuarentena para impedir que los sistemas, activos o aplicaciones afectados se comuniquen con cualquier otro elemento que no sea una herramienta de seguridad. Implica medidas rápidas como aislar los sistemas afectados, bloquear el tráfico malicioso o desactivar las cuentas comprometidas para evitar daños mayores mientras se desarrolla una solución más permanente.
Contar con una estrategia de contención a corto plazo es un paso fundamental para limitar el impacto inmediato de un incidente de seguridad. Contribuye a mantener las operaciones empresariales y a minimizar las interrupciones durante las fases iniciales de la gestión de incidentes.
[Lea también: ¿Qué es la gestión de activos de TI? [Explicación del ITAM]
La contención a largo plazo es una solución que se ha implementado en toda la empresa, aunque podría considerarse que no supone una corrección completa de la causa raíz del incidente. Una estrategia de contención a largo plazo en la respuesta ante incidentes tiene por objeto ofrecer una solución sostenible a las brechas de seguridad, garantizando que la amenaza no solo se controle de forma temporal, sino que también se evite que vuelva a producirse. Esto puede implicar actualizaciones del sistema, la gestión de parches, la segmentación de la red o la implementación de protocolos de seguridad avanzados.
Por ejemplo, ¿tiene alguna vulnerabilidad sin parchear relacionada con un incidente? De ser así, la aceleración del calendario de parches para el software en cuestión —ya sea una aplicación o un sistema operativo— debería incluirse como parte de una estrategia de contención a largo plazo.
Otra tarea fundamental que debe incluirse durante el proceso de contención es revisar qué usuarios tienen acceso administrativo y a qué sistemas, tales como:
- ¿Cuál es su superficie de ataque en relación con Active Directory?
- ¿Ha activado la autenticación multifactorial?
Es recomendable contar con estrategias de contención a largo plazo vinculadas a sus sistemas de copia de seguridad y recuperación de datos, ya que esto puede contribuir a aumentar la probabilidad de que sus datos se hayan duplicado correctamente y sean fácilmente recuperables hasta un estado anterior al incidente.
Paso 4. Erradicar
Ahora está intentando eliminar la causa de la filtración —de raíz, como se suele decir—. ¿Qué significa eso? Esto significa, por ejemplo, que en el caso de un programa malicioso que haya detectado, podrá eliminar de forma segura todas las instancias del mismo que pueda identificar. Ha reforzado la seguridad y ha aplicado parches a los sistemas cuando ha sido necesario. Ha reinstalado sistemas que no puede reforzar. Ha actualizado su inteligencia sobre amenazas para asegurarse de poder identificar los artefactos relacionados con la filtración.
A medida que se desarrolla el proceso de gestión de incidentes, es posible que cambie el alcance de sus esfuerzos. Tras un ataque de ransomware, por ejemplo, es posible que tenga muchos sistemas que deban reinstalarse y restaurarse a partir de su última copia de seguridad válida conocida. Y si no detecta todos los rastros relacionados con el ataque o no ha solucionado la vulnerabilidad que se aprovechó para acceder al sistema, podría volver a ser objeto de un ataque.
La clave para la erradicación es la minuciosidad. La pregunta fundamental es si lo ha encontrado todo —sea lo que sea «eso»—. A menudo, un socio o un tercero con conocimientos especializados puede ayudar en la limpieza.
Paso 5. Recuperar
Pasar de la erradicación a la recuperación es como salir de una intervención quirúrgica. El daño ya está hecho, y ahora es el momento de centrarnos en la recuperación.
Desde el punto de vista de la respuesta ante incidentes, es hora de ser muy sincero consigo mismo y responder a lo siguiente:
- ¿Cuándo podrán volver a poner en funcionamiento los sistemas afectados?
- ¿Ha aplicado los parches, ha reforzado la seguridad y los ha probado?
- ¿Ha utilizado su equipo de simulación de ataques (red team) interno de para llevar a cabo un ataque simulado contra estos sistemas utilizando las mismas técnicas que los atacantes?
La recuperación se mide por la rapidez con la que se pueden restablecer los sistemas y procesos afectados a su estado funcional anterior a la violación de seguridad. La recuperación también implica definir cómo modificará el alcance de su supervisión tras el incidente. Determine durante cuánto tiempo va a realizar el seguimiento de la actividad que provocó la filtración (por ejemplo, 30 días, tres meses o seis meses) y qué es exactamente lo que está buscando.
Una vez más, las pruebas del equipo rojo y los elementos recopilados durante la contención resultarán de gran ayuda en este sentido. Al finalizar la fase de recuperación, lo que desea es poder afirmar: «Hemos solucionado las vulnerabilidades, y aquí está la prueba».
Existe una marcada tendencia entre los profesionales de la seguridad a reducir el tiempo medio de reparación (MTTR), es decir, el tiempo que se tarda en completar las fases de identificación, contención y erradicación. A medida que los planes de respuesta ante incidentes (IR) se perfeccionen y los equipos adquieran mayor destreza en su aplicación, el tiempo medio de reparación (MTTR) y el tiempo medio de detección ( , MTTD) deberían reducirse. El seguimiento de estos indicadores a lo largo del tiempo puede ayudarle a comprender si el marco PICERL constituye un modelo eficaz de respuesta ante incidentes para su organización.
Paso 6. Lecciones aprendidas
Esta fase debería comenzar con una reunión de análisis posterior al incidente en la que participen todos los miembros del equipo de respuesta a incidentes y de los departamentos relacionados, como los de seguridad de la información, cumplimiento normativo, asuntos jurídicos, relaciones públicas, etc. Aquí es donde puede revisar y documentar lo que ha aprendido sobre el incidente, por ejemplo:
- ¿Qué parte de su plan de relaciones con inversores ha funcionado bien? ¿Qué no funcionó?
- ¿Hubo algún momento en el que se necesitara personal adicional? ¿Era necesario que nos pusiéramos en contacto con un tercero o con un equipo interno que no figurara en nuestra lista de recursos?
- A la luz de este incidente, ¿deberíamos modificar nuestra forma de actuar?
- ¿Estábamos utilizando de forma eficaz las herramientas de las que disponíamos? ¿Estaban configurados correctamente?
- ¿Cómo fue la comunicación entre los equipos? ¿Se podría mejorar?
- ¿Hubo algún factor relacionado con el personal en la filtración, como un ataque de ingeniería social del tipo « » o una gestión inadecuada de los datos? ¿Se puede solucionar esto mediante formación?
- ¿La vulnerabilidad aprovechada era exclusiva de una línea de negocio o era generalizada en toda la organización?
- ¿Podríamos hacer frente a esta vulnerabilidad utilizando una estructura o un proceso operativo diferente?
Cuanto más flexible sea el plan de respuesta ante incidentes, más aprenderá de un incidente cuando este se produzca. A continuación, todo lo que aprenda debería incorporarse a su fase de preparación para perfeccionarlo y mejorarlo.
¿Se diferencia el PICERL del NIST?
PICERL y el Marco de Ciberseguridad del NIST ( ) son metodologías muy utilizadas para la respuesta ante incidentes, pero difieren en su estructura y enfoque.
[Read also: Operationalizing the NIST Cybersecurity Framework 2.0 with Tanium]
PICERL ofrece un enfoque secuencial para la gestión de un incidente de seguridad que consta de seis fases. Por el contrario, el NIST constituye un conjunto de directrices más amplio y flexible, estructurado en torno a cinco funciones básicas (identificar, proteger, detectar, responder y recuperarse) para ayudar a las organizaciones a gestionar los riesgos de ciberseguridad.
PICERL es un manual detallado para la respuesta ante incidentes, mientras que el marco del NIST constituye una guía más exhaustiva para la gestión global de los riesgos de ciberseguridad . No obstante, se considera en general que el marco del NIST no es prescriptivo y que únicamente ofrece una taxonomía de resultados de ciberseguridad de alto nivel, así como enlaces a recursos para alcanzar dichos resultados.
¿Qué implica esto para su plan de respuesta ante incidentes? Las organizaciones suelen utilizar PICERL para la respuesta ante incidentes en el contexto más amplio del marco del NIST, con el fin de gestionar eficazmente los riesgos de ciberseguridad.
¿Es PICERL el mejor modelo de respuesta ante incidentes?
PICERL ofrece un enfoque detallado y estructurado para la respuesta ante incidentes, lo que puede resultar de gran utilidad para las organizaciones de mayor tamaño o aquellas con entornos informáticos más complejos. No obstante, el marco PICERL también puede plantear retos, como la necesidad de una preparación exhaustiva, la posible complejidad a la hora de identificar y contener incidentes, y la necesidad de garantizar que todo el personal cuente con la formación adecuada.
Estos retos han allanado el camino para la aparición de nuevos modelos de respuesta ante incidentes, diseñados para ofrecer enfoques más flexibles en comparación con marcos que incorporan procesos ágiles, como el PICERL, y suponen un punto de inflexión crucial en la forma en que las organizaciones deben replantearse las estrategias necesarias para llevar a cabo una respuesta eficaz ante incidentes.
Uno de estos modelos es SOAR, es decir, « S» (Supervisión y análisis de eventos de seguridad), «» (Detección de amenazas), « » (Seguridad), «O» () (Orquestación), « » (A) () (Automatización) y « » (R) () (Respuesta). SOAR se centra en la automatización de las respuestas y puede resultar especialmente útil para aquellas organizaciones que cuentan con recursos limitados a la hora de gestionar incidentes que requieren una respuesta inmediata.
Del mismo modo, el enfoque « » (DAIR), o « » (D)«ynamic» ( ) «A»«pproach» ( ) «I»«ncident» ( ) «R»«esponse», también está ganando popularidad porque hace hincapié en abordar la respuesta ante incidentes mediante puntos de referencia o hitos, que no tienen por qué producirse en orden secuencial como en el caso de PICERL. El modelo DAIR le orienta para que se centre en los resultados y en las actividades que contribuyen a alcanzarlos, en lugar de seguir un enfoque por fases.
Dada la naturaleza caótica de las amenazas cibernéticas, la capacidad de hacer frente con rapidez a ataques cada vez más sofisticados implica que los planes modernos de respuesta ante incidentes y las herramientas que los respaldan deben ser capaces de adaptarse y solucionar las amenazas con rapidez, y hacerlo con presupuestos más ajustados y ante una escasez e e de personal cualificado en ciberseguridad.
Dado que los incidentes de seguridad actuales no siguen un manual de normas, ¿por qué debería hacerlo su plan de respuesta ante incidentes?
Cómo elegir un marco de respuesta ante incidentes
En esta entrada, hemos visto cómo PICERL ha destacado tradicionalmente en el panorama de los modelos de seguridad al ofrecer una hoja de ruta detallada para la respuesta ante incidentes. No obstante, cada modelo de respuesta ante incidentes presenta sus puntos fuertes y sus dificultades.
En definitiva, los planes de respuesta ante incidentes que aplica su organización deben adaptarse a los retos específicos de ciberseguridad de su sector. Para que los planes de respuesta a incidentes (IR) sean eficaces, deben aprovechar de manera eficiente los recursos, las herramientas y el personal disponibles, al tiempo que demuestren ser aplicables en situaciones reales y adaptables para hacer frente a las nuevas amenazas a medida que surjan.
La mejora y la evolución continuas de su plan de respuesta ante incidentes son fundamentales para mantenerse a la vanguardia en materia de ciberseguridad. Ya se trate de PICERL, DAIR u otro modelo diseñado específicamente para satisfacer las necesidades de su organización, la clave reside en elaborar un plan que aborde las necesidades de seguridad actuales y prepare a su organización para hacer frente con confianza a las futuras amenazas cibernéticas.
Tanium ofrece un soporte de ciberseguridad sin igual para todos los marcos de trabajo gracias a Tanium Incident Response, que sustituye las herramientas puntuales y aisladas por una solución unificada que permite a las organizaciones identificar, gestionar y corregir las vulnerabilidades con rapidez.
Tanium potencia las capacidades de sus herramientas actuales de SIEM y EDR, transformando las tareas de detección de amenazas y respuesta ante incidentes en medidas de defensa proactivas que garantizan una interrupción mínima de la productividad de los usuarios y refuerzan su ciberresiliencia.
Al aprovechar la visibilidad en tiempo real y los datos exhaustivos de los terminales, junto con Tanium Automate, nuestra tecnología de vanguardia diseñada para automatizar tareas complejas a gran escala que requieren pocos o ningún conocimiento de programación, los equipos de cualquier tamaño y nivel de competencia pueden ganar en eficacia, productividad y eficiencia.
Concierte una demostración personalizada en directo en para ver cómo funciona Tanium en su entorno.
