Gestión de incidentes de ciberseguridad

Tiempo de lectura estimado: 18 minutos

Esta conferencia magistral pertenece al Módulo 7 “Gestión de incidentes. Buenas prácticas en cibercrisis: Especial referencia Ransomware” de C1b3rWall Academy 2021/2022. El objetivo de la misma es conocer la gestión de un caso práctico de incidente de seguridad.

Incidente de seguridad

Un evento o una serie de eventos de seguridad de la información no deseados o inesperados que tienen una probabilidad significativa de comprometer las operaciones comerciales y amenazar la seguridad de la información, afectando a la confidencialidad, la integridad y disponibilidad. (ISO 27000)

En todas las organizaciones existen debilidades y/o vulnerabilidades que pueden ser explotadas de manera intencionada o no intencionada e incumplan la Política de Seguridad de la Información de la organización, en el caso de que disponga de ella. 

Un incidente de seguridad no es igual en diferentes sectores y organismos. Es importante conocer si la empresa es privada o pública, ya que algunas fases dependen de esto, y lo más importante, les aplica determinada legislación.

• Sector público o privado
• Infraestructura crítica o redes militares y de defensa
  
  

Legislación aplicable

• RD3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad (ENS) en el ámbito de la Administración Electrónica.
• RD951/2015, de 23 de octubre, de modificación del RD 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica.
• Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público.
• RD Ley 12/2018, de 7 de septiembre, de Seguridad de las Redes y Sistemas de Información.
• Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y Garantía Derechos Digitales
• Guía Nacional de Notificación y Gestión de Ciberincidentes. Aprobada por el Consejo Nacional de Ciberseguridad el 21-2-2021
• Real Decreto 704/2011, de 20 de mayo, por el que se aprueba el Reglamento de protección de las Infraestructuras Críticas.
  
  

¿Se ha producido un incidente?

Dependiendo del ataque en ocasiones no es sencillo identificar si somos víctimas de un incidente de ciberseguridad. Se necesitan empleados concienciados para identificar signos de un posible problema, pero cuando sucede ¿qué debemos hacer?

• Monitorizar adecuadamente los sistemas
• Implantar herramientas de correlación y revisión de logs
• Implementar un servicio de ciberinteligencia
• Concienciación a usuarios de comunicar cualquier sospecha
• El eslabón más débil en cuanto incidentes de seguridad siempre es el propio personal
  
  

Primeros momentos. Plan de respuesta a incidentes

La respuesta suele venir por el Centro de Atención a Usuarios, que alguien le ha notificado un incidente. El plan de respuesta a incidentes debe ser detallado y exhaustivo, una guía que realmente nos ayude y sepamos en todo momento si estamos dando los pasos adecuados o si nos hemos dejado alguno.

Este manual suele contener algunas fases comunes: contención, detección, mitigación, comunicación, recuperación de la información y servicios y prevención. Si ya tenemos el plan establecido necesitamos un equipo que dé respuesta a estos incidentes: director de respuesta a incidentes, analista de seguridad, servicios jurídicos, director de TI y líder de comunicación.

Cada uno tendrá responsabilidades específicas y funciones claras. Pueden variar dependiendo del sector y la empresa, y del riesgo del activo a proteger. Este equipo debe estar entrenado para el día que suceda.

Alcance del incidente. Contexto

Hay que realizar una valoración para conocer el contexto, para ello podemos hacernos algunas preguntas:

• ¿Nuestra empresa tiene las políticas y procedimientos necesarios?
• ¿Están implementados en herramientas que automaticen su proceso?
• ¿Contamos con un equipo de TI propio? ¿Con los profesionales adecuados?
• ¿La Dirección está concienciada sobre ciberincidentes? ¿Y los empleados?
• Grado de madurez de la organización
  

Resolviendo el incidente

En la fase de detección nos pueden llegar indicativos por diferentes vías. Como hemos dicho, el Centro Atención a Usuarios (CAU) que recoge incidencias de usuarios y/o clientes.

Algunos indicadores son eventos que nos señalan que posiblemente un incidente ha ocurrido, como alertas en sistemas de seguridad, caídas de servidores, reportes de usuarios, software antivirus dando informes y otros funcionamientos fuera de lo normal del sistema.

La identificación y gestión de elementos que alertan sobre un incidente nos proveen información que puede alertarnos sobre la futura ocurrencia del mismo y preparar procedimientos para minimizar su impacto. Algunos de estos elementos pueden ser: logs de servidores, logs de aplicaciones, logs de herramientas de seguridad o cualquier otra herramienta que permita la identificación de un incidente de seguridad.

En la entidad debe existir un listado de fuentes generadoras de eventos que permitan la identificación de un incidente de seguridad de la información.

Resolviendo el incidente. Contención

Impidiendo que el incidente se extienda a otros recursos; como consecuencia se minimiza su impacto.

Resolviendo el incidente. Evaluación

Inicialmente hay que tener en cuenta el análisis de riesgos de la entidad y la clasificación de los activos. Así como la severidad del incidente en cuanto a su impacto. Clasificaremos la amenaza según su origen, sistemas, usuarios afectados… e incluiremos una serie de variables que podrán ser utilizadas para realizar la evaluación de los incidentes en base a análisis de riesgo previos, como la prioridad, criticidad de impacto, impacto actual e impacto futuro.

Resolviendo el incidente. Mitigación

Después de que el incidente ha sido contenido y evaluado, se procede a la eliminación de los elementos comprometidos, en caso de ser necesario y posible, y reinstalación de sistemas afectados o backups.

Resolviendo el incidente. Peligrosidad e impacto

Debe ser acorde al nivel de peligrosidad y del impacto pero siempre hay que hacerlo, sobre todo a los afectados y stakeholders. Es primordial establecer una colaboración público privada, pues son los canales principales para alertar a otros organismos. También notificarlo a las autoridades:

• INCIBE: Dpto. de Respuesta a Incidentes (CERT)
• CCN: Centro Criptológico Nacional (CERT)
• CNPIC: Centro Nacional de Protección de Infraestructuras y Ciberseguridad
• AEPD: Agencia Española de Protección de Datos
• Fuerzas y Cuerpos de Seguridad del Estado
  
  

Resolviendo el incidente. Comunicación a AEPD

• Hay que comunicar, en menos de 48 horas
• Identificar el tratamiento de datos afectados
• Intencionalidad y origen. Revelación oral, robo, incidencia técnica, mostrar datos a un tercero
• Tipología. Confidencialidad, disponibilidad e integridad
• Categoría de datos. Básicos, contactos, salud, biométricos
• Perfil de los afectados. Clientes, alumnos, empleados,...
• Consecuencias. Imposibilidad de ejercer algún derecho, daños reputacionales, perdida
• confidencialidad, pérdida de control sobre datos…
• Severidad
• Información de la brecha y medios de detección
• Medidas de seguridad previas y post
• Comunicación a interesados
  
  

Resolviendo el incidente. Recuperación de información y servicio

Consiste en devolver el nivel de operación a su estado normal y que las áreas de negocio afectadas puedan retomar su actividad. Debemos aprovechar para robustecer el sistema ante este tipo u otros de ataque y no precipitarse en la puesta en producción de sistemas y buscar cualquier signo de actividad sospechosa, definiendo un periodo de tiempo con medidas adicionales de monitorización.

Los elementos básicos para la recuperación de un incidente:

• Backup de Información
• Imágenes de servidores
• Cualquier información base que pueda recuperar el funcionamiento normal del sistema
  
  

Resolviendo el incidente. Prevención

Hay que reflexionar sobre lo sucedido, la causa del problema, cómo se ha gestionado el ciberincidente, los problemas que hemos tenido y la asignación de responsabilidades administrativas, penales y civiles. También deberíamos hacer un informe en el que se detalle la causa, el coste económico, el impacto en los servicios, y las medidas a tomar en el futuro para prevenir los ataques.

Nuevos marcos reguladores

Se avecina el nuevo Reglamento de Resiliencia Operacional Digital (DORA), que se prevé su publicación a finales de 2022. Su objetivo es agilizar el proceso de gestión de riesgos de terceros en todas las instituciones financieras mediante cinco pilares clave:

• Gestión de riesgos de TIC
• Notificación de incidentes de TIC
• Pruebas de residencia operativa digital
• Intercambio de información e inteligencia
• Gestión de riesgos de terceros de TIC

Además contamos con la directiva europea NIS 2.0. Está pretende reforzar los requisitos de seguridad con una lista de medidas, como la respuesta a incidentes y la gestión de crisis, tratamiento y divulgación de vulnerabilidades y pruebas de ciberseguridad y uso eficaz del cifrado. También reforzará la seguridad de la cadena de suministro, y se hará responsable a la dirección de la empresa por el cumplimiento de las medidas.

Peritaje informático

Para identificar a los atacantes y las vulnerabilidades explotadas se utilizarán procesos de naturaleza legal. El peritaje informático tiene como objetivo conseguir que una evidencia informática que contiene cierta información relevante para un procedimiento judicial entre a formar parte de dicho procedimiento como prueba.

Este trabajo ha de realizarse sobre evidencias obtenidas con un procedimiento estandarizado de identificación, adquisición y análisis de evidencia, para que sea ratificado ante la autoridad judicial.

A modo de resumen podemos hacer referencia a la frase de Sun Tzu: “Conócete a ti mismo y saldrás triunfador en mil batallas.”

¿Todavía no formas parte de C1b3rWall Academy? El contenido es gratuito, únete a otras 30.000 personas desde este enlace.

Si te interesa este tema, puedes consultar la información y cursar el Máster en Ciberseguridad o ver la oferta de másteres desde aquí.

Ponente: Ricardo Barrasa García

CIO de DLTCode y antiguo presidente de ISACA Madrid. Es Ingeniero de Sistemas por la UPM y máster en Administración y Dirección de Empresas por ICADE. Cuenta con las certificaciones CISA, CISM y CDPSE (ISACA) y DPD (AEPD). Es miembro del comité de Expertos Independientes de Estrategia de Ciberseguridad Nacional 2019 y profesor asociado en varias universidades.