Antes que nada os animo a visitar el blog de INCIBE: https://www.incibe.es/protege-tu-empresa/blog
En este artículo se dedica un espacio a la «respuesta a incidentes» más enfocado a la empresa que a un particular.
En este último artículo dedicado a la respuesta a incidentes, analizaremos los pasos que se deben seguir una vez nos hemos recuperado de un incidente.
Si hacemos una recapitulación de los dos artículos anteriores, los puntos tratados son:
- Primeros pasos en la respuesta a incidentes:
- evaluación inicial del incidente,
- comunicación del incidente,
- contención de daños y minimización de los riesgos.
- Respuesta a incidentes: tomando evidencias y recuperando la actividad.
- Identificación de la gravedad del ataque,
- protección de las pruebas,
- notificación a organismos externos,
- recuperación de los sistemas afectados,
- lecciones aprendidas.
Esta última fase de respuesta al incidente la dividiremos en tres procesos de gran importancia que servirán para que no vuelva a suceder un incidente similar y, en caso de que ocurra, estar preparados.
Documentar los detalles del incidente
Documentar todo lo sucedido nos servirá para comprender el incidente y evaluar las acciones tomadas. Con esto podemos aprender de nuestros errores y reforzar las buenas prácticas por si vuelve a ocurrir y para intentar evitarlo en el futuro. En la documentación deberá constar:
- Descripción del incidente. Hay que indicar en qué fecha y hora se identificó el incidente. Además es conveniente aportar otro tipo de información como:
- Tipología del incidente: revisar el tipo de incidente que se ha sufrido. Aunque esta acción ya se realizó anteriormente, es necesario volver a estudiarla ya que antes no se contaba con toda la información. En caso de haber sido indicada correctamente, reafirmar la tipología elegida: ransomware, fuga de información, denegación de servicio, etc.
- Recursos afectados, con qué gravedad y cómo afectó a la empresa. Registra los recursos afectados y en qué medida (por ejemplo por tiempo de inactividad o si hubo que reponerlos). También registra si fue necesario detener servicios, avisar a clientes o proveedores, etc.
- Qué acciones se tomaron para solventarlo, cuándo se llevaron a cabo y por qué se hizo así.
- Evidencias recogidas durante todo el proceso, por ejemplo correos recibidos, o ficheros o unidades de disco cifrados.
- Posible origen. Indicar cuál ha podido ser el origen del incidente en base a todos los pasos de los dos artículos anteriores. También se registrará si ya ha sido resuelto.
- Personal involucrado. Todas las personas que han participado de un modo u otro en la resolución del incidente deben estar identificadas convenientemente.
- Fecha y hora de resolución del incidente. Se ha de llevar un registro secuencial de actuaciones.
El proceso de documentación debe comenzar desde que se identifica el incidente de seguridad. Para que la comprensión de toda la documentación generada sea más sencilla, se debe organizar cronológicamente y debe estar firmada por el responsable encargado. En algunos casos, es conveniente que durante todo el proceso un perito informático tome evidencias sobre lo sucedido, ya que de esta manera tendremos garantía de que las pruebas serán tratadas correctamente y serán admisibles en un juicio.
Valorar los daños y costes del incidente
Hay que determinar lo más meticulosamente posible los daños causados por el incidente, ya sean directos como indirectos. De esta manera, podrán ser aportados como pruebas en un juicio de cara a una posible reclamación. Estos costes pueden incluir:
- reposición de equipos o su software;
- los daños reputacionales debidos, por ejemplo, a la divulgación de información confidencial;
- legales;
- los asociados a la recuperación de la actividad normal y análisis del incidente;
- los debidos al tiempo de inactividad o lucro cesante.
Revisar las políticas de la empresa: lecciones aprendidas
Una vez concluido todo el proceso, documentado debidamente y cuando la actividad haya vuelto a la normalidad, llegará el momento de recapitular y hacerse varias preguntas:
- ¿Qué ha fallado para que se produjera el incidente?
- ¿Qué política de seguridad no ha funcionado?
- ¿Qué hay que mejorar para que no vuelva a suceder? ¿He informado a los empleados de lo que ha ocurrido? ¿Es necesario formar a los empleados para que sepan cómo actuar en estos casos?
- ¿La gestión del incidente fue correcta?
- ¿Qué pasos se pueden mejorar para hacer la gestión del incidente más fluida?
- En caso de tener que hacer el incidente público, ¿la comunicación con los medios fue correcta y fluida?
- ¿Se realizó un ejercicio de transparencia con la opinión pública o por el contrario las comunicaciones fueron opacas?
- Si el incidente afectó a información privada de clientes o proveedores, ¿se realizó la comunicación en tiempo y forma?
Gestionar un incidente de manera correcta no se reduce únicamente a restaurar los sistemas y servicios afectados o aplicar las medidas de seguridad necesarias para que no vuelva a suceder. Tan importante es recuperar la actividad cotidiana de la organización como documentar correctamente todo lo sucedido, valorar los daños o revisar las políticas de la empresa. Con estas «lecciones aprendidas» estaremos mejor preparados para detener un incidente similar.
Latest posts by Jose Miguel (see all)
- Artículo: Guía completa de seguridad en el uso de redes Wi-Fi en entornos empresariales y públicos. - 23 septiembre, 2024
- Artículo: Cómo reaccionar ante un ataque de Phishing: Guía para Usuarios Empresariales - 20 septiembre, 2024
- Artículo: Guía básica para la gestión de contraseñas y usuarios en navegadores populares. - 20 septiembre, 2024
- Artículo: La importancia de las copias de seguridad en la ámbito empresarial: Guía Práctica. - 18 septiembre, 2024
- Artículo: Mejorando la ciberseguridad en el entorno laboral: Guía práctica para Empleados. - 16 septiembre, 2024