Skip to content

La delgada línea entre las actividades de prevención y resolución de incidentes de seguridad de la información

Publicado por Sergio Hernando el 8 septiembre 2008

Hola,

El otro día, conversando con un amigo, surgió un debate a la hora de situar la línea entre las actividades previas y posteriores al acontecimiento de un incidente de seguridad.

La línea entre el pre y el post tiende a hacerse cada vez más difusa, ya que muchas actividades de prevención son el soporte para las actividades de investigación. Yo quiero pensar que todas las actividades de prevención deberían ser el comienzo de las actividades de resolución de incidentes, o al menos, deberían servir para resolverlos, con lo que mi postura es clara: esa línea no debe existir, y si existe, sólo debería ser para repartir y coordinar esfuerzos, constituyendo equipos especializados, uno en cada disciplina, pero gobernados por una dirección común y con una intensa interactuación e interrelación. Parece igualmente lógico admitir la diferenciación si tenemos propósitos didácticos, persiguiendo enfatizar en los contenidos de las actividades del ciclo de prevención y respuesta ante incidentes.

La monitorización de un log es un ejemplo clásico donde podemos prevenir incidentes de seguridad, explotando y extrayendo inteligencia en forma de alertas. La mera existencia del log nos permitirá disponer de datos para cuando hayamos empezado a reaccionar. Dispondremos de hilo del que tirar para tomar nota de las condiciones de contorno del incidente y ver cómo se ha desenvuelto el problema a partir de ese momento.

Me cuesta pensar en actividades de prevención que sólo sirvan para prevenir. Quizás si consideramos actividad al mero hecho de generar, priorizar y escalar alarmas que proceden de un log, tendremos una actividad distinta a la investigación del log. De todos modos, esta división sólo tiene sentido, en mi humilde opinión, para poder asignar responsabilidades a cada una de las tareas de prevención y resolución, o bien para explicar los conceptos de manera aislada si perseguimos aleccionar a alguien. Separarlas en dos entes distintos bajo la creencia de que una no tiene que ver con la otra parece que no tiene sentido.

¿Por qué sigue siendo frecuente encontrar en la literatura conceptos separados como la prevención de incidentes y la respuesta ante incidentes, y no algo parecido a prevención y respuesta ante incidentes? El debate se puede volver más complejo si dividimos y extendemos a los conceptos de prevención, detección, respuesta y recuperación ante incidentes. Aunque son parte de un ciclo único, hay muchos autores que prefieren atomizar entre esas cuatro actividades, si bien de entrada, la prevención y la detección (pre) son una pareja clara, y la respuesta y la recuperación son otra dupla diferenciada (post)

En resumen, si quiere hablarse en términos didácticos conviene diferenciar, para comprender las etapas de un ciclo, pero a la hora de aplicar estos preceptos a la vida real, cuantas menos distinciones hagamos mejor, precisamente por la naturaleza cíclica que hemos comentado. En estos casos, la única distinción que parece procedente es la necesaria para organizar equipos de trabajo, sin perder nunca de vista que el objetivo del ciclo es cerrarlo, y que por tanto, los equipos que realicen actividades bien de prevención, detección, respuesta y/o recuperación ante eventos e incidentes seguridad deben remar en la misma dirección, produciendo resultados unificados.

Algunas lecturas:

IT Security Prevention, Detection, Response, and Recovery

NIST Special Publication 800-61 - Computer Security Incident Handling Guide

NIST Guide to Malware Incident Prevention and Handling

SANS Institute - Corporate Incident Handling Guidelines

CHIHT - Clearing House for Incident Handling Tools

Be Sociable, Share!

Categoría/s → Forensics, Malware, Seguridad

Un comentario
  1. 9 septiembre 2008

    Comparto contigo que la linea que las separa es muy delgada pero dentro del ciclo de prevención, detección, respuesta y/o recuperación, la frontera empieza cuando se llega a la detección del incidente.

    En la prevención el objetivo es la vigilancia activa para reducir la vulnerabilidad, evitar que ocurra a toda costa pero en ese estado, por así decirlo, todavía no ha saltado la alarma. El perfil técnico del personal que realiza estas tareas sería similar al personal de operación de los sistemas más ciertos conocimientos de seguridad que les permitan saber cuando las alarmas han saltado.

    Ahora, una vez que nos encontramos en la fase de detección el enfoque cambia. El equipo que atiende el incidente debe tener por objetivo reducir el tiempo de impacto para que los daños se minimicen. Yo entiendo que es en ese momento cuando comienza la fase de respuesta(tratar de parar el incidente cuanto antes). En este caso, pueden mezclarse dos tipos de perfiles: técnicos que intenten detener el ataque y forenses que garanticen la conservación de las evidencias digitales para su posterior análisis.

    Una vez logrado esto, ya podríamos hablar del incio de las fases de recuperación para hacer que las cosas vuelvan a la normalidad.

    También se plantea una problemática importante debido a la naturaleza de las actividades que deben comentar en la fase de respuesta y recuperación. Si el incidente que se produce va a generar algún tipo de proceso judicial, se deben contemplar las actividades forenses para recoger evidencias digitales suficientes que puedan luego apoyar las denuncias pertinentes. ¿Qué ocurre si las actividades de respuesta/recuperación son incompatibles con las tareas forenses previas? ¿Qué debe primar?
    Imaginemos un caso donde el procedimiento de respuesta suponga la restauración de una imagen del servidor desde la ultima copia.
    Por eso es tan importante el diseño de planes de contingencia y continuidad de negocio. No se debe improvisar ni reaccionar de manera descoordinada. Todo debe estar pensado y desde todas las perspectivas (operativa, jurídica, seguridad de la información, imagen corporativa,…)

Escribir un comentario

Note: XHTML permitido. Tu email nunca será publicado.

Suscribirse a los comentarios via RSS