gestionar un incidente de seguridad de la información

Pasos para gestionar un incidente de seguridad de la información en IT

Compartir

Si alguna vez te has preguntado cuáles son los pasos para gestionar un incidente de seguridad de la información en IT con éxito, este artículo te ayudará a comprenderlo. Si no te lo has preguntado nunca y trabajas en IT deberías saber cómo se gestiona, porque por suerte o por desgracia no vivimos en el país de “My Little Pony” y aquí las cosas tienden a torcerse.

De entrada, debemos decir que existen distintas aproximaciones a la gestión de incidentes propuestas por distintos organismos, normas y frameworks (marcos de trabajo). Como ya sabemos, cuando hay posibilidad de especificar estándares o formas de trabajo, siempre hay organismos dispuestos a dar su propia visión que, en general, a pesar de ser más o menos acertados, si extrapolamos un poco y lo miramos a vista de pájaro, siempre tienen una base común. Como suelo decir siempre, todas estas normas (ISO 27.001, ISO 22.301, ENS, Cobit, etc.), por muchas vueltas que les demos, están basadas en el sentido común.

En este artículo vamos a ver una aproximación simplista en la que vamos a hablar de 6 pasos, aunque lo primero que debemos entender es que para gestionar los incidentes de seguridad de manera más o menos efectiva se requiere de una gran inversión en la fase de preparación, aunque no nos referimos a una inversión económica sino más bien de tiempo. Es recomendable aprovechar tiempos libres en los que no hay nada que hacer o en los que la carga de trabajo es menor para diseñar, planificar, documentar y practicar.

Además de todo esto, se debe crear una política de comunicación clara que nos permita gestionar las notificaciones hacia el exterior de la empresa, con mensajes a través de RRSS o notificaciones a los clientes a la par que gestionar los flujos de información sobre el avance y tratamiento del incidente de manera interna.

Por supuesto, se deberá abogar por una postura donde se potencie el aprendizaje de las situaciones y emergencias previas y la adaptación a nuevos métodos, procesos, etc., para fortalecer la postura de seguridad de la organización, todo ello con el objetivo de potenciar continuamente la resiliencia de la empresa.

Siguiendo estos preceptos y aplicando los pasos que se pasan a describir, una empresa de IT puede mitigar el impacto de un incidente de seguridad y fortalecer su postura de seguridad a largo plazo.

Tras revisar distintos modelos, describimos los siguientes pasos:

  • Paso 1: Preparación.
  • Paso 2: Identificación del incidente.
  • Paso 3: Contención del incidente.
  • Paso 4: Erradicación del incidente.
  • Paso 5: Recuperación de la normalidad.
  • Paso 6: Normalidad post-incidente.

Una vez propuestos, vamos a ver cada uno de ellos explicados de manera más o menos profunda.

 

Paso 1: Preparación:

Esta es la fase o el paso en el que más tiempo y esfuerzo se debe dedicar. Tomaremos una referencia a “300” de Frank Miller, donde Leonidas le dice a su hijo que “quien suda más entrenando, sangra menos en la batalla” y en base a ella deberemos decir que no hay nada más cierto bajo el cielo, pues aquellas organizaciones que invierten tiempo en mejorar sus sistemas, su seguridad, la formación de sus empleados y de sus procesos serán más capaces de sobrevivir a un incidente de seguridad.

Dentro de este paso tenemos cosas tan distintas como la concienciación de los empleados en general, la formación de los equipos técnicos para saber cómo deben operar o trabajar en determinadas condiciones o frente a distintas incidencias, etc.

Aquí definimos toda la parte de políticas de seguridad de la organización, incluyendo desarrollar y documentar políticas y procedimientos de respuesta a incidentes, teniendo en cuenta también la inclusión de los roles y responsabilidades que se deben adaptar de manera clara, sobre todo para las personas que deben ejercerlos, así como procedimientos específicos para diferentes tipos de incidentes que deben ser definidos en base a los riesgos que previamente se hayan definido.

Dentro de esta parte de preparación para el futuro, se debe adoptar la postura de asegurarse de tener las herramientas y recursos necesarios para detectar, analizar y mitigar todo tipo de incidentes de seguridad. Entre los elementos necesarios se debe incluir software de monitorización de seguridad, gestores de logs, analizadores de logs, firewalls, asesoramiento por parte de consultores o expertos en seguridad, inversión en equipamiento y herramientas forenses, etc.

Por último, dentro de esta sección se debe tener en cuenta la organización de un equipo de respuesta a incidentes de seguridad en el que se integren los miembros con las habilidades, conocimientos y herramientas necesarios para poder enfrentar incidentes de seguridad de la manera más efectiva.

 

Paso 2: Identificación del incidente:

La identificación de incidentes suele dividirse en dos subapartados: la detección y la evaluación.

La detección utiliza herramientas de monitorización y detección para identificar posibles incidentes de seguridad, incluyendo sistemas de detección de intrusiones (IDS), sistemas de protección de intrusiones (IPS), sistemas de información y gestión de eventos de seguridad (SIEM), así como distintas herramientas de análisis de logs.

La evaluación se usa para que, una vez se haya identificado el posible incidente de seguridad, se pueda evaluar la naturaleza y el alcance del mismo.

En este punto se debe tener en cuenta que se deben ir afinando los sistemas poco a poco para ir purgando los posibles falsos positivos y que solo queden los incidentes reales para los cuales se deba de activar el siguiente paso con una respuesta encaminada a la contención del incidente.

 

Paso 3: Contención del incidente:

En este punto se debe proceder a intentar minimizar el alcance del incidente o lo que es lo mismo, intentar que los daños que genere el incidente sean lo menos graves posible. Por ello deberemos proceder a tomar medidas inmediatas para contener el incidente y evitar que este se siga propagando.

Dentro de estas medidas se pueden tener procedimientos de bloqueo de direcciones IP desde las que lleguen ataques, aislar estaciones de trabajo sospechosas de estar infectadas por virus, bloquear accesos, o matar procesos dentro de un servidor.

Además, una vez se contiene la primera oleada, la más inmediata se pasará a contener de manera un poco más extensa, con la vista puesta en el corto plazo pero no en la inmediatez. En este punto es en el que estableceremos medidas para mitigar el impacto del incidente mientras un equipo especializado desarrolla soluciones permanentes para el incidente de seguridad.

Dentro de estas medidas tendremos opciones como el bloqueo de cuentas, parcheo de servidores o establecimiento de nuevas reglas de nuestros cortafuegos.

 

Paso 4: Erradicación del incidente:

El paso de la erradicación del incidente de seguridad consiste en conseguir identificar la causa raíz del incidente con el propósito de eliminarla para después pasar a realizar la limpieza, si es que se ha identificado correctamente, y proceder a la recuperación.

Dentro de esta parte se tienen puntos como la limpieza o recuperación de sistemas comprometidos, recuperación de backups, cierre de vulnerabilidades de aplicaciones, o la eliminación del malware.

Cuando se pasa a la parte de limpieza dentro de este paso, se trata de asegurar de que todos los rastros del incidente, o mejor dicho de la causa raíz del incidente, han sido eliminados.

 

Paso 5: Recuperación de la normalidad:

La recuperación de la normalidad es básicamente el objetivo de todo cuanto hacemos a lo largo de esta operativa. Tenemos como objetivo el restaurar el correcto funcionamiento de los servicios y sistemas de nuestra organización para que el funcionamiento de nuestros procesos pase a ser completamente operativo y la producción no se vea afectada.

Dentro del proceso encontraremos pasos como restaurar los sistemas y servicios afectados a su estado original, o sea, recuperación al estado normal de operación incluyendo la restauración de datos desde copias de seguridad, el formateo de los sistemas y la reinstalación del sistema operativo y del resto del software que integra los sistemas.

Es recomendable realizar varios análisis posteriores para confirmar que ya no hay amenazas y que se ha erradicado completamente el motivo causante del incidente.

 

Paso 6: Normalidad post-incidente:

Tras el incidente, una vez normalizada la situación, se deben realizar una serie de tareas como por ejemplo una retrospectiva, una revisión post-incidente para analizar lo que se ha hecho bien, lo que se ha hecho mal, lo que se puede mejorar, etc. Dentro de todo esto se establece siempre una evaluación de la efectividad de los distintos procesos que se han realizado, así como la valoración de la efectividad de las políticas y por supuesto el desempeño del equipo de respuesta a incidentes.

Tras esto se deberán poner en marcha las mejoras y actualizaciones correspondientes en las políticas, procedimientos y herramientas de respuesta a incidentes basándonos en la información extraída de la retrospectiva.

Dentro de este proceso de mejora, se debe poner especial hincapié en la capacitación del personal según los errores cometidos o necesidades detectadas.

Por supuesto, se deben elaborar los informes pertinentes para dejar documentados todos los aspectos relacionados con el incidente, incluyendo el procedimiento de detección, el procedimiento de respuesta, y las lecciones aprendidas.

 

Bonus: Comunicación:

Además de los pasos descritos, haremos una mención especial a la comunicación, que no recibe el “rango” de paso porque debe ser transversal a todos los pasos aquí descritos. Se debe tener una política de notificaciones del incidente a las partes interesadas, además de notificar la situación a miembros de la dirección a distintos departamentos afectados, etc. Se debe tener en cuenta a todos aquellos a los que se deba mantener informados, incluyendo en caso de así ser descrito en las políticas (paso 1), a clientes y autoridades.

Mucho ojo a la gestión de las comunicaciones. De ello hablaremos en otra ocasión porque no es algo que se debe improvisar y, aunque parezca extraño siendo un técnico de sistemas, recomendaré que la política de comunicación se realice de manera conjunta, preparándola entre el departamento de sistemas, el departamento de seguridad (si existe), producción, etc., pero las comunicaciones, notificaciones y demás en caso de ser necesarias deben gestionarse  desde el departamento de marketing y/o comunicación, ya que ellos están acostumbrados a enviar mensajes de la mejor manera posible, no como los de sistemas que en ocasiones somos un poco “especiales”.

 

Conclusiones:

Tal como hemos visto en el artículo los pasos para gestionar un incidente de seguridad de la información en IT con éxito, la forma de gestionar los incidentes no es única, sino que disponemos de distintos enfoques dependientes de normas internacionales, normas nacionales, marcos de trabajo, y un largo etcétera.

Así mismo, hemos visto que tenemos la opción de seguir unos pasos para gestionar los incidentes de seguridad de manera más o menos eficiente, aunque todo depende una vez más de tener el apoyo de la dirección y de planificar e invertir tiempo cuando no hay incidentes de seguridad para estar preparados cuando estos lleguen.

Si quieres aprender más sobre seguridad, te recomendamos echar un ojo a estos otros artículos de nuestro blog.

¡Gracias por leernos!

Categorías:Recursos Sysadmin

Otros posts que te pueden interesar

12 de julio de 2024
A lo largo de las siguientes líneas vamos a hacer una breve review de Windows Server 2025 en la
3 de julio de 2024
Disaster Recovery de Jotelulu es una solución diseñada pensando en la pyme. ¿Qué argumentos debería utilizar la empresa de
2 de julio de 2024
Continúa leyéndonos si quieres saber cuáles son las principales claves para entender un plan de Disaster Recovery con JOTELULU.

Rellena el formulario y nuestro equipo de Sales contactará contigo lo antes posible.

growth@jotelulu.com  |  +34 911 333 712  |  jotelulu.com 

Puedes darte de baja de estas comunicaciones en cualquier momento.  Consulta nuestra Política de privacidad.

Precios competitivos para la pyme y mucho más margen para el partner

Disaster Recovery ha sido diseñado, implementado y puesto en producción teniendo en cuenta dos premisas: Debe tener un precio atractivo para la pyme a la vez que deja un buen margen de beneficio a la empresa de IT que lo comercializa y gestiona.

DR_buen_precio_y_mas_margen

De esta manera, Disaster Recovery pretende ser un producto diferencial que permita incrementar la seguridad de todo tipo de empresas de manera asequible e implicando, además, rentabilidad para el distribuidor que lo comercializa.

Protege la infraestructura de tus clientes

Disaster Recovery permite replicar cualquier suscripción de infraestructura (Escritorio Remoto y Servidores) en otra zona de disponibilidad creando un entorno de alta disponibilidad y blindando así el servicio.

Replica en pocos pasos no sólo los discos sino todos los elementos que forman parte de cada suscripción:

  • Servidores: Instancias, discos, reglas de firewall, redes, IPs…
  • Escritorio Remoto: Usuarios, Aplicaciones, Licencias, Personalización…
DR_blinda_la_infraestructura

Tratamos de hacer fácil lo difícil

Las herramientas de Disaster Recovery existentes necesitan de conocimientos avanzados para poder ser gestionadas, implicando, muchas veces, un expertise difícil de alcanzar.

 

Disaster Recovery de Jotelulu busca hacer fácil lo difícil y plantea un despliegue muy sencillo basado en una configuración de tres pasos:

Origin (Primary Site)
Determina la ubicación de origen de la suscripción sobre la que se va a establecer el servicio de Disaster Recovery.

Destino (Recovery Site)
Establece la ubicación de destino (zona de disponibilidad) en la que quieres que se despliegue el Recovery Site.

Características de la réplica
Establece los datos asociados al número de copias que se quieren guardar y la frecuencia con la que se va a llevar a cabo la réplica.