Gestión de Incidentes
La gestión de incidentes es un área de procesos perteneciente a la gestión de servicios de tecnologías de la información. El primer objetivo de la gestión de incidentes es recuperar el nivel habitual de funcionamiento del servicio y minimizar en todo lo posible el impacto negativo en la organización de forma que la calidad del servicio y la disponibilidad se mantengan. (Wikipedia)
Un incidente son posibles o probables amenazas cuando interviene el factor humano. (Detrás de la acción se encuentra la naturaleza humana)
Vector de ataque: es la vía que se utiliza para obtener información o acceso. (Por donde viene el fallo)
La meta en la gestión de incidentes es averiguar el qué, cómo, cuándo, dónde, por qué, para qué y para quién vino o fue el fallo.
Estas averiguaciones las realizamos a través de las entrevistas, evidencias, conclusiones (causa/efecto) y realizando una evaluación de riesgo (documento de seguridad).
Incidentes de Seguridad
Por Incidente de Seguridad entendemos cualquier evento que pueda provocar una interrupción o degradación de los servicios ofrecidos por el sistema, o bien afectar a la confidencialidad, o integridad de la información.
Un incidente de seguridad puede ser causado por un acto intencionado realizado por un usuario interno o un atacante externo para utilizar, manipular, destruir o tener acceso a información y/o recursos de forma no autorizada.
La LOPD define una incidencia como “cualquier anomalía que afecte o pudiera afectar a la seguridad de los datos”.
Plan de Respuesta a Incidentes
La definición e implantación a un plan de respuesta a incidentes debería tener en cuenta una serie de actividades y tareas, entre las cuales podríamos destacar todas las que se presentan en la siguiente relación:
- Constitución de un equipo de Respuesta de Incidentes
- Definición de una Guía de Procedimientos
- Detección de un incidente de seguridad
- Análisis del incidente.
- Contención, erradicación y recuperación
- Identificación del atacante y posibles actuaciones legales
- Comunicación con terceros y relaciones públicas
- Documentación del incidente de seguridad
- Análisis y revisión “a posteriori” del incidente
Equipo de Respuesta de Incidentes de Seguridad Informática (CSIRT)
El equipo de CSIRT (Computer Security Response Team) está constituido por las personas que cuentan con la experiencia y la formación necesaria para poder actuar ante las incidencias y desastres que pudieran afectar a la seguridad informática de la organización.
En la mayoría de las organizaciones que no cuentan con un equipo de Respuesta de Incidentes formalmente constituido será necesario identificar quiénes son las personas responsables de acometer cada una de las tareas que se hayan definido en el Plan de Respuesta de Incidentes, definiendo claramente las responsabilidades, funciones y obligaciones de cada persona implicada en dicho plan.
La organización deberá mantener actualizada la lista de contacto para emergencias, para poder localizar rápidamente a personas claves.
Procedimientos y actividades a realizar
La organización debe definir una guía de actuación clara y detallada con los procedimientos y acciones necesarias para la restauración rápida, eficiente y segura de la capacidad de procesamiento informático y de comunicaciones de la organización, así como para la recuperación de los datos dañados o destruidos.
El objetivo de la guía de procedimientos es conseguir una respuesta sistemática ante los incidentes de seguridad. También debe tratar de forma adecuada las cuestiones legales que se pudieran derivar de cada incidente de seguridad, así como los aspectos relacionados con la imagen y reputación de la organización y las relaciones públicas.
Detección de un Incidente de Seguridad
Se debe prestar atención a los posibles indicadores de un incidente de seguridad. Relación de los principales indicadores de posibles incidencias de seguridad:
- Precursores de un ataque: actividades previas de reconocimiento del sistema informático, como el escaneo de puertos, escaneo de vulnerabilidades en servidores, el reconocimiento de versiones de sistemas operativos y aplicaciones, etc.
- Alarmas generadas en los Sistemas de Detección de Intrusos (IDS), en los cortafuegos o en las herramientas antivirus.
- Registro de actividad extraña en los logs de servidores y dispositivos de red o incremento sustancial del número de entradas en los logs.
- Aparición de nuevas carpetas o ficheros con nombres extraños en el servidor, o modificaciones realizadas en determinados ficheros del sistema (liberías, kernel, aplicaciones críticas, etc.), que se pueden detectar mediante herramientas de revisión de la integridad de ficheros.
- Caída o mal funcionamiento de algún servidor: reinicios inesperados o fallos en algunos servicios, aparición de mensajes de error, incremento anormal de la carga del procesador o del consumo de memoria del sistema, etc.
- Notable caída en el rendimiento de la red o de algún servidor, debido a un incremento inusual del tráfico de datos.
- Cambios en la configuración de determinados equipos de la red: modificación de las políticas de seguridad y auditoría, activación de nuevos servicios, puertos abiertos que no estaban autorizados, activación de las tarjetas de red en modo promiscuo (para poder capturar todo el tráfico que circula por la red interna mediante “sniffers”), etc.
- Existencia de herramientas no autorizadas en el sistema.
- Aparición de nuevas cuentas de usuarios o registros de actividad inusual en algunas cuentas: conexiones de usuarios en unos horarios extraños (por ejemplo, por la noche o durante un fin de semana), utilización de la misma cuenta desde distintos equipos a la vez, bloqueo reiterado de cuentas por fallos en la autenticación, ejecución inusual de determinados servicios desde algunas cuentas, etc.
- Informes de los propios usuarios del sistema alertando de algún comportamiento extraño o de su imposibilidad de acceder a ciertos servicios.
- Detección de procesos extraños en ejecución dentro de un sistema, que se inician a horas pocos habituales o que consumen más recursos de los normales (tiempo de procesador o memoria).
- Generación de tráfico extraño en la red: envío de mensajes de correo electrónico hacia el exterior con contenido sospechoso, inusual actividad de transferencia de ficheros, escaneo de otros equipos desde un equipo interno, etc.
- Notificación de un intento de ataque lanzado contra terceros desde equipos pertenecientes a la propia organización.
- Desaparición de equipos de red de la organización.
- Aparición de dispositivos extraños conectados directamente a la red o a algunos equipos de la organización (en este últimos caso podrías ser por ejemplo, dispositivos para la captura de pulsaciones de teclado en los equipos)
La gran cantidad de información que se genera en los “logs” y en las distintas herramientas de seguridad puede dificultar su posterior estudio, debido sobre todo a la pérdida de tiempo provocada por los “falsos positivos”. Por este motivo, es necesario contar con herramientas y filtros que faciliten la detección y clasificación de incidentes.
Análisis de un incidente de Seguridad
El Plan de Respuesta de Incidentes debe definir ¿Cómo el equipo de respuesta debería proceder al análisis de un posible incidente de seguridad? En cuanto éste fuese detectado por la organización, determinando en primer lugar ¿Cuál es su Alcance? ¿Qué equipos, redes, servicios y/o aplicaciones se ha podido ver afectados? ¿Se ha podido comprometer información confidencial de la organización o de sus usuarios y clientes?¿Ha podido afectar a terceros?
- Seguidamente el equipo de respuesta debería determinar cómo se ha producido el incidente:
- Cómo se ha producido el incidente
- Qué tipo de ataque informático (si lo ha habido) ha sido el causante
- Qué vulnerabilidades del sistema han sido explotadas
- Qué métodos ha empleado el atacante
- Etc.
Se podría utilizar una Matriz de Diagnóstico para facilitar la actuación del equipo en momentos de máximo estrés, evitando que se puedan tomar decisiones precipitadas que conduzcan a errores, constituyendo además de un valioso apoyo para el personal con menos experiencia en la actuación frente a incidentes de seguridad.
| Síntoma | Código Malicioso | Denegación de Servicio | Acceso no autorizado |
| Escaneo de Puertos | Bajo | Alto | Medio |
| Caída de Servidor | Alto | Alto | Medio |
| Modificación de ficheros de un equipo | Alto | Bajo | Alto |
| Tráfico inusual en la red | Medio | Alto | Medio |
| Ralentización de los equipos o de la red | Medio | Alto | Bajo |
| Envío de mensajes de correo sospechosos | Alto | Bajo | Medio |
Así mismo conviene hacer una valoración inicial de los daños y de sus posibles consecuencias, para a continuación establecer un orden de prioridades en las actividades que debería llevar a cabo el equipo de respuesta.
El documento RFC 1244 y RFC 2196 propone la siguiente priorización:
- Prioridad uno: proteger la vida humana y la seguridad de las personas
- Prioridad dos: proteger datos e información sensible de la organización
- Prioridad tres: proteger otros datos e información de la organización
- Prioridad cuatro: prevenir daños en los sistemas informáticos (pérdida o modificación de ficheros básicos para las aplicaciones y los servidores)
- Prioridad cinco: minimizar la interrupción de los servicios ofrecidos a los distintos usuarios (internos o externos)
Contenido, Erradicación y Recuperación
El equipo de respuesta debe elegir una determinada estrategia de contención del incidente de seguridad.
Una primera alternativa para un nivel muy alto de riesgo podría ser apagar todos los equipos afectados, desconexión de estos equipos a la red de informática, etc.
Una segunda alternativa es retrasar la contención para poder estudiar con más detalle el tipo de incidente y tratar de averiguar quién es el responsable del mismo. Esta estrategia se puede adoptar siempre y cuando sea posible monitorizar y controlar la actuación de los atacantes, para este modo reunir evidencias.
La erradicación es la etapa del Plan de Respuesta a Incidentes en la que se llevan a cabo todas las actividades necesarias para eliminar los agentes causantes del incidente y de sus secuelas, entre las que podríamos citar posibles “puertas traseras” instaladas en los equipos afectados, rootkies u otros códigos maliciosos, etc.
Por último la recuperación es la etapa del Plan de Respuesta de Incidentes en la que se trata de restaurar los sistemas para que puedan volver a su normal funcionamiento. Para ello, será necesario contemplar tareas como la reinstalación del sistema operativo y de las aplicaciones partiendo de una copia de seguridad, configuración adecuada de los servicios e instalaciones de los últimos parches, actualizaciones de seguridad, etc.
Identificación del atacante y posibles actuaciones legales
Dentro del Plan de Respuestas de Incidentes, la identificación del atacante es necesaria para poder emprender acciones legales para exigir responsabilidades y reclamar indemnizaciones.
Existen distintas técnicas para determinar la dirección de IP (ping, traceroute, whois, etc.) Pero hay que tener en cuenta una serie de obstáculos como:
- IP Spoofing: enmascara la dirección en algunos tipos de ataques.
- El atacante podría estar usando equipos de terceros
- Podrían estar utilizando direcciones de IP dinámicas
- El equipo atacante podría estar de un servidor proxy
- Etc.
También ayuda a identificar al atacante los sistemas de escaneos, logs, IDS, etc.
Se recomienda presentar una denuncia contra el atacante, a las unidades policiales especializadas en este tipo de incidentes o ataques informáticos.
Comunicación con terceros y Relaciones Públicas
Debería estar previsto los contactos con organismos de respuesta a incidentes de seguridad informática (como el CERT), con las fuerzas de seguridad (Policía o Guardia Civil en España), con agencias de investigación y con los servicios jurídicos de la organización.
También se deben contemplar los contactos con terceros que pudieran haber sido perjudicados por el incidente de seguridad, como en el caso de que se hubieran utilizado ordenadores de la organización para realizar un ataque contra sistema y redes de otras entidades. De este modo, se podrían limitar las responsabilidades legales en las que podría incurrir la organización por culpa del incidente de seguridad.
Tener en cuenta el cumplimiento de la normativa existente ya en algunos países, se obliga a la notificación de los incidentes de seguridad a determinados organismos de la Administración.
Documentación del Incidente de Seguridad
Se debe reflejar en forma clara y precisa aspectos como los que se presentan en la siguiente relación:
- Descripción del tipo de incidente
- Hechos registrados (eventos en los logs de los equipos).
- Daños producidos en el sistema informático
- Decisiones y actuaciones del equipo de respuesta
- Comunicaciones que se han realizado con terceros y con los medios
- Lista de evidencias obtenidas durante el análisis y la investigación
- Comentarios e impresiones del personal involucrado
- Posibles actuaciones y recomendaciones para reforzar la seguridad y evitar incidentes similares en el futuro.
Análisis y revisión a posteriori del incidente
Se debe aprender del incidente ocurrido. Se deberá realizar un informe final sobre el incidente, en el que se pueden desarrollar los siguientes aspectos de forma detallada:
Investigación sobre las causas y las consecuencias del incidente:
- Estudio de la documentación generada por el equipo de respuesta de incidentes.
- Revisión detallada de los registros de actividad “logs” de los ordenadores y dispositivos afectados por el incidente.
- Evaluación del coste del incidente de seguridad para la organización: equipos dañados, software que se haya visto afectado, datos destruidos, horas de personal dedicado a la recuperación de los equipos y los datos, información confidencial comprometida, necesidad de soporte técnico externo, etc.
- Análisis de las consecuencias que haya podido tener para terceros.
- Revisión del intercambio de información sobre el incidente con otras empresas e instituciones, así como con los medios de comunicación.
- Seguimiento de las posibles acciones legales emprendidas contra los responsables del incidente.
Revisión de las decisiones y actuaciones del equipo de respuesta a incidentes:
- Composición y organización de equipos
- Formación y nivel de desempeño de los miembros
- Rapidez en las actuaciones y decisiones: ¿Cómo respondió el personal involucrado en el incidente?;¿qué tipo de información se obtuvo para gestionar el incidente?¿qué decisiones se adoptaron?
Análisis de los procedimientos y de los medios técnicos empleados en la respuesta de incidente:
- Redefinición de aquellos procedimientos que no hayan resultado adecuados.
- Adopción de las medidas correctivas que se consideren necesarias para mejorar la respuesta ante futuros incidentes de seguridad.
- Adquisición de herramientas y recursos para reforzar la seguridad del sistema y la respuesta ante futuros incidentes de seguridad.
Revisión de las Políticas de Seguridad de la Organización:
- Definición de nuevas directrices y revisión de las actualmente previstas por la organización para reforzar la seguridad de sus sistemas.
Prácticas recomendadas por el CERT/CC
Preparación de la respuesta ante incidentes de seguridad
- Definición del plan de actuación y los procedimientos para responder a los incidentes, especificando, entre otras cuestiones, a quién se debe informar en caso de incidente o qué tipo de información se debe facilitar y en qué momento (fase de incidente).
- Documentación del plan de actuación y de los procedimientos para responder a los incidentes.
- Comprobación de que el plan de actuación y los procedimientos previstos cumplen con los requisitos legales y las obligaciones contractuales con terceros (como, por ejemplo, exigencias de los clientes de la organización).
- Adquisición e instalación de herramientas informáticas y dispositivos que faciliten la respuesta ante incidentes. Conviene disponer de equipos redundantes, dispositivos de red y medios de almacenamiento para poder recuperar el funcionamiento normal del sistema.
- Verificación de los procedimientos y dispositivos de copias de seguridad.
- Creación de un archivo de discos de arranque y un conjunto de copias con todas las aplicaciones y servicios necesarios para el funcionamiento de los sistemas informáticos, así como de los parches y actualizaciones correspondientes.
- Formación y entrenamiento del personal afectado por este plan y procedimientos de actuación.
- Mantenimiento actualizado de una base de datos de contactos (personas y organizaciones).
Seguimiento del incidente de seguridad
Realización de un nuevo análisis detallado de las vulnerabilidades y riesgos del sistema informático. Recurriendo para ello al análisis post mórtem de los equipos afectados por el incidente y entrevistando a las personas implicadas en la gestión del incidente de seguridad.
Implementación de las mejoras de seguridad propuestas como consecuencia de las “lecciones aprendidas” en cada incidente de seguridad: revisión de las políticas y procedimientos de seguridad.
Obligación Legal de Notificación de Ataques e Incidencias
Todas las Websites de comercio electrónico están obligados por ley a informar a sus clientes cuando se haya producido una violación de la seguridad de sus sistema de informático.
Esta alerta informatica se tendrá que enviar tanto en caso de robo de información como cuando hayan sido descubiertas brechas de seguridad en el Website de la empresa.