Josemi 24 mayo 2023

Compartir:

Una de nuestras recomendaciones de seguridad para clientes es que elaboren un plan de respuesta a incidentes para uso interno en su negocio. A continuación facilitamos un ejemplo. Si quiere que le ayudemos a mejorar la seguridad de su negocio, contáctenos. Estamos especializados en digitalizar pequeños negocios.

Nota importante: Cada negocio debe establecer su propio plan de respuesta a incidentes conforme a sus circunstancias, necesidades específicas y cualquier normativa que le sea aplicable. Esto es simplemente un ejemplo y no es reemplazo de una auditoría informática ni constituye asesoramiento legal. No proporcionamos ninguna garantía ni asumimos ninguna responsabilidad al respecto.

Este plan de ejemplo es propiedad intelectual de JD Services y todos sus derechos quedan reservados. Como clarificación, este plan de ejemplo es diferente del que usamos internamente.

1.    Introducción

Este plan constituye un conjunto de medidas y procedimientos destinados a prevenir, detectar, analizar y limitar cualquier incidente o responder ante este y recuperarse de él.

Nunca debe descartarse o hacer caso omiso a cualquier cuasi incidente, incidente de seguridad, ciberamenaza o reporte.

Este plan de respuesta a incidentes, pudiera ser necesario ejecutarlo simultáneamente al Pllan de continuidad de negocio (BCP), en caso de que el incidente afecte a la continuidad operativa.

Como clarificación, este documento no anula ni reemplaza cualquier obligación legal que pueda ser aplicable.

2.    Definiciones

A efectos de este plan, se considerarán las siguientes definiciones:

• Cuasi incidente: un hecho que habría podido comprometer la disponibilidad, autenticidad, integridad o confidencialidad de los datos almacenados, transmitidos o tratados, o los servicios ofrecidos por sistemas de redes y de información o accesibles a través de ellos, pero cuya materialización completa se previno de manera satisfactoria o que no llegó a materializarse. Algunos ejemplos incluyen: recibir correos electrónicos con malware o sospechosos (aun cuando no se hayan abierto/ejecutado), detección de sistemas infectados con virus, intentos de ingeniería social, sufrir intentos de ciberataques sin que se lleguen a materializar.
• Ciberamenaza: una circunstancia, un evento o una acción potencial capaz de dañar, interrumpir o afectar de forma adversa a las redes y a los sistemas de información, así como a sus usuarios y otras partes interesadas.
• Ciberamenaza significativa: una ciberamenaza que, basándose en sus características técnicas, cabe suponer que tiene el potencial de provocar repercusiones graves en los sistemas de redes y de información de una entidad o para los usuarios de los servicios de la entidad causando perjuicios materiales o inmateriales considerables
• Incidente de seguridad: todo hecho que comprometa la disponibilidad, autenticidad, integridad o confidencialidad de la información y datos (personales o no) almacenados, transmitidos o tratados, o los servicios ofrecidos por sistemas digitales o accesibles a través de sistemas digitales.
• Incidente de seguridad significativo: un incidente de seguridad que
  • ha causado o puede causar graves perturbaciones operativas de los servicios o pérdidas económicas para nuestro negocio, o
  • ha afectado o puede afectar a otras personas físicas o negocios al causar perjuicios materiales o inmateriales considerables
• Datos personales: toda información sobre una persona física (“interesado”) identificada o identificable (directa o indirectamente). Incluyendo, sin limitación, datos básicos, datos de contacto, imágenes/videos, documentos identificativos, datos económicos o financieros, datos de localización, medios de pago, credenciales de acceso o identificación, datos de perfiles, datos sobre la vida sexual, religión o creencias, origen racial o étnicos, datos de salud, opiniones políticas, datos genéticos), datos sobre afiliación sindical, datos biométricos, datos sobre condenas e infracciones, etc.
• Datos personales tratados por cuenta de un cliente: Datos personales de terceras personas, responsabilidad de un cliente nuestro. Típicamente datos de clientes del cliente, tratados como encargados por el responsable.
• Brecha de datos personales: toda violación de la seguridad que ocasione la destrucción, pérdida o alteración accidental o ilícita de datos personales transmitidos, conservados o tratados de otra forma, o la comunicación o acceso no autorizados a dichos datos personales. Como clarificación, no todas las brechas de datos personales implican necesariamente que se haya comprometido la seguridad técnica de los sistemas. A su vez, no todo incumplimiento de la normativa de protección de datos aplicable es considerado necesariamente una brecha de datos personales. Algunos ejemplos incluyen, sin limitación, revelaciones verbales no autorizadas, documentación perdida o robada, eliminación incorrecta de datos personales, datos personales enviados por error, datos personales eliminados o destruidos, abuso de privilegios para extraer/reenviar/copiar datos personales, datos personales residuales en dispositivos obsoletos, publicaciones no intencionadas/autorizadas, envío de correo electrónico a múltiples destinatarios sin copia oculta, dispositivos perdidos o robados, secuestros de información, suplantaciones de identidad, compromiso de cuentas de usuario, acceso no autorizados a datos personales, incidencias técnicas, modificaciones no autorizadas de datos personales, datos personales divulgados al individuo incorrecto, etc.
• CSIRT: Equipo de respuesta a incidentes de seguridad informática
• Autoridad de control: Autoridad estatal responsable de supervisar el cumplimiento de la normativa de protección de datos aplicable
• Autoridad policial: Cuerpo de cumplimiento de la ley ante cibercrímenes. Puede ser diferente en función de donde haya sucedido el crimen (online o presencial).

3.    Autoridades relevantes

Respecto a incidentes de seguridad de nuestra empresa, las autoridades relevantes serán:

• CSIRT: XXXXXXXXXX
• Autoridad de control: XXXXXX
• Autoridad policial: XXXXXXXX para crímenes online o, la policia local correspondiente para crímenes presenciales

Las autoridades relevantes para contratistas, clientes y proveedores son diferentes de las de nuestra empresa.

4.    Directrices generales

Durante un incidente de seguridad, es crítico:

• Mantener la calma: Los incidentes son extremadamente disruptivos y tienen una carga emocional. Debemos mantener la calma y focalizarnos en priorizar los esfuerzos en las acciones con mayor impacto primero.
• Mantener el foco: En los datos críticos para el negocio, el impacto a clientes y preparar la remediación.
• Mantener una perspectiva de negocio: Siempre considerando el impacto en la operativa del negocio de las acciones del adversario y nuestras propias acciones de respuesta.
• No dañar: Se debe confirmar que la respuesta es diseñada y ejecutada de forma que evita la pérdida de datos, la pérdida de funcionalidad crítica del negocio y la pérdida de evidencias (por ejemplo, los correos de phishing maliciosos no deben eliminarse manualmente). Se deben evitar las decisiones que puedan dañar la habilidad de crear cronogramas forenses, identificar las causas raíz y aprender lecciones críticas.
• Considerar las implicaciones legales: Colaborando activamente con las autoridades durante la investigación y recuperación, según sea necesario.
• Ser cuidadosos al compartir públicamente información sobre el incidente: No compartir nada con los clientes o el público sin autorización o un procedimiento establecido.
• Obtener ayuda cuando se necesite: Obtener asistencia de otros compañeros o empresas, cuando se requiera para responder a ataques sofisticados.

Durante un incidente de seguridad, debemos lograr equilibrio en:

• Velocidad: Ponderando la necesidad de actuar rápido con el riesgo de decisiones precipitadas
• Compartición de información: Informar a los involucrados y afectados buscando limitar la responsabilidad y evitando establecer expectativas no realistas

5.    Proceso de gestión de incidentes

5.1.           Preparación

Todo el personal debe estar familiarizado con el contenido de este documento y, estudiarlo periódicamente, y como mínimo 1 vez al año, aunque no sucediesen incidentes.

Es importante seguir la política de seguridad informática y otros procedimientos establecidos, a fin de prevenir incidentes.

5.2.           Detección y análisis

5.2.1.      Descubrimiento de incidentes

Cualquier cuasi incidente, incidente de seguridad, brecha de datos personales o ciberamenaza debe ser reportada internamente con la máxima prioridad.

Cualquier actividad sospechosa debe ser siempre investigada inmediatamente, puesto que podría ser un indicador o precursor de un incidente de seguridad. Los minutos importan.

5.2.2.      Investigación del incidente

Ante cualquier incidente se debe:

• determinar el nivel de impacto
• estudiar su correlación con otros eventos
• en caso de múltiples eventos, priorizar adecuadamente los mismos
• si es posible, identificar los datos o sistemas objetivo del ataque (los atacantes persistentes frecuentemente vuelven por su objetivo en un ataque futuro)
• notificar a todo el personal que participará del proceso de respuesta, y establecer los roles y coordinación necesarios

Para el análisis, puede ser especialmente util el uso de Defender para Empresas (disponible para clientes de nuestro servicio MSP). No se recomienda el uso de escáneres online como VirusTotal.

Debe tenerse claro que podría ser imposible identificar el ataque inicial, porque los datos requeridos para ello podrian haber sido eliminados antes de empezar la investigación, al limpiar su rastro el propio atacante.

No se debe alargar la investigación infinitamente, sino priorizar los esfuerzos. En caso de incidentes mayores, puede ser practicamente imposible investigar todos los recursos comprometidos.

5.2.3.      Notificación temprana a CSIRT

En el caso de cualquier incidente de seguridad significativo, sin demora indebida y en el plazo máximo de 24 horas desde que se haya tenido constancia, remitiremos al CSIRT una alerta temprana que indique como mínimo si:

• cabe sospechar que el incidente significativo responde a una acción ilícita o malintencionada
• puede tener repercusiones transfronterizas

5.2.4.      Notificación a proveedores

Cuando creamos que el incidente pueda poner en riesgo nuestro uso de los servicios que recibamos de terceros, debemos notificar el incidente a dichos proveedores con fines de coordinación y cooperación.

Debe considerarse el riesgo de que nuestra identidad sea suplantada ante dichos proveedores o se vean comprometidas las cuentas con los mismos.

Son considerados potencialmente críticos los proveedores que nos proporcionen los siguientes servicios:

• Conexión a internet o telecomunicaciones
• Servicios financieros
• Contabilidad y servicios legales
• Recursos humanos
• CRM
• Redes sociales
• Soluciones de ciberseguridad
• Servicios gestionados
• Hosting
• Dominios

5.2.5.      Notificación a clientes

Cuando un incidente de seguridad significativo sea susceptible de afectar negativamente a la prestación de nuestros servicios, deberemos notificar sin demora indebida a los clientes afectados.

Asimismo, cuando se haya producido una brecha de datos personales tratados por cuenta de un cliente, deberemos enviar notificación inmediata a los clientes responsables de los mismos, la cual deberá como mínimo:

• describir la naturaleza de la violación de la seguridad de los datos personales, inclusive, cuando sea posible, las categorías y el número aproximado de interesados afectados, y las categorías y el número aproximado de registros de datos personales afectados
• comunicar el nombre y los datos de nuestro punto de contacto en el que pueda obtenerse más información
• describir las posibles consecuencias de la violación de la seguridad de los datos personales
• describir las medidas adoptadas o propuestas para poner remedio a la violación de la seguridad de los datos personales, incluyendo, si procede, las medidas adoptadas para mitigar los posibles efectos negativos

Cuando los clientes de nuestros servicios puedan verse afectados por una ciberamenaza significativa, deberemos sin demora indebida comunicarles:

• las medidas o soluciones que dichos destinatarios pueden aplicar en respuesta a la amenaza
• cuando proceda, la propia ciberamenaza

5.3.           Contención, erradicación y recuperación

5.3.1.      Contención

Cuando sea relevante, la primera prioridad debe ser contener la intrusión antes de que el adversario pueda acceder a más recursos o causar más daños. El objetivo primario debe ser limitar el impacto a nuestros datos y los de nuestros clientes.

Salvo que nos enfrentemos a una amenaza inminente de pérdida de datos del negocio (eliminación, encriptación, filtración) debe ponderarse el riesgo de no llevar a cabo una modificación con el impacto en el negocio. Se debe tener en cuenta que las acciones que busquen crear disrupción al atacante también podrían impactar negativamente al negocio.

Si se requiere realizar cambios temporales, en los que el riesgo de no tomar la acción es mayor que el riesgo de tomarla, estos deben documentarse a fin de poder revertir las acciones temporales después de la fase de recuperación.

5.3.2.      Erradicación

Se debe eliminar, con un alto grado de confianza, la causa raíz del incidente de seguridad con el objetivo de:

• Expulsar al adversario completamente de nuestros sistemas
• Mitigar la vulnerabilidad (si se conoce) que permitió o podría permitir al adversario reentrar en nuestros sistemas

Dependiendo de la naturaleza del incidente, su ámbito, profundidad y posibles repercusiones se deberán utilizar diferentes técnicas de erradicación.

No se deben descuidar otros aspectos de ciberseguridad normal operativa por la atención requerida por el incidente.

Es importante tener en cuenta que debemos evitar destruir cualquier evidencia encontrada (por ejemplo, cualquier malware debe bloquearse o ponerse en cuarentena, pero no eliminarse).

Dependiendo de la naturaleza y ámbito del ataque, podemos limpiar los artefactos (archivos, emails, puntos de conexión, identidades, etc.) conforme se encuentran, o alternativamente construir una lista de recursos comprometidos para posteriormente limpiarlos todos a la vez (“Big Bang”):

• Limpiar sobre la marcha: Método adecuado para la mayoría de incidentes típicos que sean detectados en una fase temprana de la operación de ataque. Pone al adversario en desventaja y previene que sigan adelante con la siguiente fase de su ataque.
• Preparar para un Big Bang: Este método es adecuado cuando el adversario ya ha entrado y se ha establecido dentro de nuestros sistemas. En estos casos, se debe evitar alertar al atacante con nuestras acciones de limpieza, hasta que se haya descubierto al completo la presencia del atacante, para que la sorpresa ayude a crear disrupción completa de su operación.

5.3.3.      Recuperación

Una vez se tenga un nivel razonable de confianza de que el adversario ha sido expulsado de los sistemas y todas las rutas de vulnerabilidad posibles han sido eliminadas, se deberán iniciar pasos para restaurar la operativa a un estado normal.

Esta actividad puede requerir el Plan de recuperación de desastres (DRP) correspondiente para restaurar copias de seguridad.

Al ejecutar la recuperación es prioritario:

• Tener un plan claro y de ámbito limitado: Aunque los planes pueden cambiar en base a la actividad del adversario o nueva información, debemos trabajar diligentemente para limitar la expansión del ámbito y la adicción de tareas adicionales
• Tener responsabilidades claras: Típicamente las operaciones de recuperación implican a múltiples personas u organizaciones ejecutando diferentes tareas simultáneamente, por lo que es fundamental estar bien coordinados.
• Mantener comunicación con todos los involucrados: Se debe trabajar proporcionando actualizaciones puntuales y gestionar activamente las expectativas

Un aspecto clave de la recuperación es tener vigilancia reforzada y controles preparados para validar que el plan de recuperación ha sido ejecutado exitosamente, y no existan señales de brecha.

En caso de estar abrumados o no tener seguridad sobre cómo actuar, se debe considerar solicitar asistencia o servicios externos.

5.3.4.      Notificación completa a CSIRT

En el caso de cualquier incidente de seguridad significativo, sin demora indebida y en el plazo máximo de 72 horas desde que se haya tenido constancia, remitiremos al CSIRT una notificación completa que, como mínimo:

• actualizará, cuando proceda, la información contemplada en la alerta temprana
• se expondrá una evaluación inicial del incidente significativo, incluyendo su gravedad e impacto, así como indicadores de compromiso, cuando estén disponibles

5.3.5.      Notificación a autoridades de control

En el caso de brechas de datos personales, deberemos notificar a nuestra autoridad de control en el plazo máximo de 72 horas, excepto cuando:

1. La brecha solo haya afectado a datos tratados por cuenta de clientes, o
2. Sea improbable que la violación de seguridad constituya un riesgo para los derechos y libertades de las personas

La notificación a la autoridad de control, deberá como mínimo:

• describir la naturaleza de la violación de la seguridad de los datos personales, inclusive, cuando sea posible, las categorías y el número aproximado de interesados afectados, y las categorías y el número aproximado de registros de datos personales afectados
• comunicar el nombre y los datos de nuestro punto de contacto en el que pueda obtenerse más información
• describir las posibles consecuencias de la violación de la seguridad de los datos personales
• describir las medidas adoptadas o propuestas para poner remedio a la violación de la seguridad de los datos personales, incluyendo, si procede, las medidas adoptadas para mitigar los posibles efectos negativos

5.3.6.      Notificación a interesados

Cuando se haya producido una brecha de datos personales, deberemos notificar a los interesados afectados sin demora indebida, excepto cuando:

1. Los datos personales afectados son tratados exclusivamente por cuenta de clientes o,
2. No sea probable que la violación de la seguridad de los datos personales entrañe un alto riesgo para los derechos y libertades de las personas físicas, o
3. Hayamos tomado medidas ulteriores que garanticen que ya no exista la probabilidad de que se concretice el alto riesgo para los derechos y libertades del interesado, o
4. Existan medidas de protección que hagan ininteligibles los datos personales para cualquier persona que no esté autorizada a acceder a ellos (por ejemplo, etiquetas de confidencialidad con cifrado)

Cuando corresponda esta notificación a interesados, esta se realizará mediante contacto directo a cada interesado afectado. En aquellos casos en que suponga un esfuerzo desproporcionado, se optará en su lugar por una comunicación pública o una medida semejante por la que se informe de manera igualmente efectiva a los interesados.

Las notificaciones al interesado describirán en un lenguaje claro y sencillo la naturaleza de la violación de la seguridad de los datos personales y deberá como mínimo:

• comunicar el nombre y los datos de nuestro punto de contacto en el que pueda obtenerse más información
• describir las posibles consecuencias de la violación de la seguridad de los datos personales
• describir las medidas adoptadas o propuestas para poner remedio a la violación de la seguridad de los datos personales, incluyendo, si procede, las medidas adoptadas para mitigar los posibles efectos negativos

5.4.           Actividad post-incidente

5.4.1.      Reunión de análisis

Una vez completada la recuperación de cualquier incidente de seguridad significativo o brecha de datos personales, se llevará a cabo una reunión con el siguiente orden del día:

1. ¿Qué ocurrió exactamente, y en qué momentos?
2. ¿Cómo de bien se gestionó el incidente? ¿Se siguieron los procedimientos documentados? ¿Fueron adecuados?
3. ¿Qué información se hubiera necesitado antes?
4. ¿Hubo algún paso o acción tomada que pudiera haber inhibido la recuperación?
5. ¿Qué deberíamos hacer de manera diferente la próxima vez que un incidente similar ocurra?
6. ¿Cómo podría haberse mejorado la compartición de información con otras organizaciones? (autoridades, clientes, proveedores, etc.)
7. ¿Qué acciones correctivas pueden prevenir incidentes similares en el futuro?
8. ¿Qué precursores o indicadores deberían ser vigilados en el futuro para detectar incidentes similares?
9. ¿Qué herramientas o recursos adicionales son necesarios para detectar, analizar y mitigar incidentes futuros?

Puede ser conveniente tener estas reuniones también con otras organizaciones involucradas o afectadas.

5.4.2.      Plan de mejora

Tras cualquier incidente de seguridad significativo o brecha de datos personales, se debe realizar un plan exhaustivo de mejora de procesos. Como parte del mismo se deberá:

• Documentar la secuencia de eventos que ha causado el incidente
• Crear un resumen técnico del incidente conjunto con evidencias que incluyan a los actores involucrados en la brecha (si se conocen), así como las acciones ejecutadas y otros aprendizajes
• Identificar carencias técnicas, fallos procedurales, errores manuales, defectos de procesos, problemas de comunicación, y/o cualquier otro vector de ataques previamente desconocido que haya sido identificado durante el incidente
• Asignar tareas de mejora concretas como parte de un plan de acción

5.4.3.      Informe postmortem

En el caso de incidentes de seguridad significativos, se elaborará un informe final postmortem, a más tardar un mes después del inicio del mismo, el cual deberá enviarse a:

• CSIRT: en caso de incidentes de seguridad significativos, y/o
• Clientes responsables afectados: en el caso de brechas de datos personales tratados por cuenta de clientes

Recogerá, como mínimo, los siguientes elementos:

• una descripción detallada del incidente, incluyendo su gravedad e impacto
• el tipo de amenaza o causa principal que probablemente haya desencadenado el incidente
• las medidas paliativas aplicadas y en curso
• cuando proceda, las repercusiones transfronterizas del incidente

El informe debe contener una cronología formal y exacta de todos los sucesos.

5.4.4.      Denuncia policial

Si creemos que en relación con un incidente de seguridad ha tenido lugar un cibercrimen, debemos presentar una denuncia ante la autoridad policial correspondiente.

5.4.5.      Retención de evidencias

Se deben recopilar todas las evidencias posibles y determinar por cuanto tiempo se tendrán las evidencias y pruebas relativas al incidente.

Se deben tomar medidas técnicas para asegurar su conservación, ya que pueden ser requeridos en procesos legales. Para ello, puede utilizarse Administración del ciclo de vida de Microsoft Purview (disponible para clientes de nuestro servicio MSP).

¿Quiere contratar nuestros servicios? Solicitar información