58
Perspectiva de las AA.PP.
Análisis de incidentes
SIETE ELEMENTOS: ATACANTE, HERRAMIENTA, VULNERABILIDAD, ACCIÓN, BLANCO,
RESULTADO NO AUTORIZADO Y OBJETIVO, DEFINEN LA TAXONOMÍA DE LOS INCIDENTES
Roberto
Fañanás Conte
AUDITOR TIC
Armada Española
A
unque a lo largo de los años
se han propuesto diversas
taxonomías de incidentes,
ninguna de ellas ha logrado el
consenso de la comunidad. En 1998 el
Department of Energy de los EE. UU.
Presentó, dentro del proyecto
“Common Language Project”, una
taxonomía de los incidentes de
seguridad en las TIC. Este esquema
de clasificación define cada una de las
piezas que intervienen en un incidente
y las relaciones existentes entre ellas.
Definiciones
Así evento es cualquier cambio en
el estado de un sistema o dispositivo,
desde el punto de vista de la
seguridad dichos cambios son la
consecuencia de “acciones” dirigidas
directamente contra un “blanco”.
Acciones que pueden dirigirse a los
datos (ej. leer, copiar, modificar, robar,
etc.); a los procesos (ej. autenticar,
desbordar, evitar, etc.) y a los
componentes del sistema (ej. robar,
espiar, etc.).
Un ataque es la serie de pasos
intencionados que realizados por un
nº 10
mayo 2007
atacante a través del uso de
herramientas, tales como un
programa o una intervención física,
aprovecha una vulnerabilidad con el
objetivo de lograr un resultado no
autorizado, tal como el incremento de
su nivel de acceso (ej. robo,
corrupción de la información, etc.).
Un incidente es el conjunto de
ataques que se diferencia de otros
ataques basándose en características
como el atacante, el tipo de ataque,
los objetivos, el origen y la hora.
Prevención y solución
Así esta relación entre eventos,
ataques e incidentes sugiere que para
prevenir que un atacante pueda
alcanzar sus objetivos se debe evitar
que pueda consumar la conexión
entre los siete elementos definidos.
(Atacante, herramienta,
vulnerabilidad, acción, blanco,
resultado no autorizado y objetivo).
Prevenir incidentes es sin duda la
solución más inteligente y mantener
el número de incidentes
razonablemente bajo es un factor
clave del éxito de la gestión de la
seguridad de nuestra organización.
Las prácticas recomendadas para
asegurar sistemas, redes y
aplicaciones son la Gestión de
Actualizaciones, el bastionaje de las
máquinas, el blindaje del perímetro,
la prevención del código maligno y la
concienciación y formación de los
usuarios.
No obstante, el objetivo a cumplir
no ha de ser tanto la ausencia de
incidentes como la confianza de que
estos estén bajo control; saber que
pueden pasar y saber qué hacer
cuando pasan. No se ha de permitir
en ningún caso que un ataque pase
inadvertido, hay que detectarlo,
registrarlo y reaccionar, primero con
un plan de emergencia que pare y
limite el incidente y después con un
plan de continuidad y recuperación
que reestablezca la situación normal
de operación.
Para muchas organizaciones el
mayor desafío en el proceso de la
respuesta ante un incidente es una
detección y evaluación certera a la
hora de determinar si un incidente
está ocurriendo y si es así, el tipo,
extensión y magnitud del problema.
Las razones fundamentales de esta
dificultad son una combinación de tres
factores. Heterogeneidad de las
fuentes, motivada por los múltiples
formatos que pueden seguir las
fuentes de origen y por las diferencias
‘semánticas’ entre detectores de
distinta naturaleza. Extensión, la
enormidad del volumen de eventos
registrados por la capa de detección
en origen. Especialización, el alto
grado de formación técnica y
experiencia requeridos en el equipo de
incidencias.
La detección y el análisis de un
incidente deberían ser tareas sencillas
si pudiésemos tener certeza de la
fiabilidad, (veracidad y exactitud) de
los avisos recibidos.
60
Perspectiva de las AA.PP.
Desgraciadamente esto no es así, los
IDS son conocidos por la gran
cantidad de falsas alarmas que
generan, e incluso las indicaciones
provenientes de los usuarios de que
un servicio no está disponible son
frecuentemente incorrectas. Para
complicar todavía más las cosas el
número de indicaciones recibidas de
los sensores desplegados puede ser
de miles o incluso de millones cada
día. Discernir de entre esa maraña
cuáles de ellos son incidentes reales
de seguridad puede ser una tarea
absolutamente desalentadora.
Recursos
A pesar de la enorme diversidad de
herramientas de seguridad existentes,
las alertas, avisos de cualquier cambio
involuntario o malintencionado y las
alarmas, indicadores de que algo
anormal está ocurriendo son las
únicas señales de un incidente. Estas
señales caen en una de estas dos
categorías: precursores, señales de
nº 10
mayo 2007
que un incidente puede ocurrir en el
futuro e indicios, señales de que un
incidente puede haber ocurrido o está
ocurriendo en este momento.
Muchos de los ataques no pueden
ser detectados a través de los
precursores, ya que en algunos casos
estos precursores simplemente no
existen y en otros las organizaciones
no consiguen reconocerlos. No
obstante, si los precursores son
detectados las organizaciones tendrán
la oportunidad de prevenir el incidente
modificando su postura de seguridad
de forma automatizada; como un IPS
que detecta un comportamiento
anormal y bloquea las actividades
posteriores, o de forma manual como
la creación de una regla en el
cortafuegos.
Para facilitar esta tarea de análisis
y validación se pueden hacer algunas
cosas: Normalización de redes y
sistemas, creación de perfiles que
permita una rápida validación de la
integridad de los sistemas.
Conocimiento del comportamiento
normal de nuestros sistemas, sin
tener un sólido conocimiento de que
es lo “habitual” el definir qué es
“extraño” resulta prácticamente
imposible. Uso de sistemas
centralizados de log, que faciliten un
formato común, realicen una
consolidación de las entradas y
apliquen una política de conservación
única. Correlación de Eventos,
acceder, analizar, agrupar y relacionar
los diferentes atributos de eventos
originados en diferentes fuentes.
Sondas de recolección, que recojan
información detallada de los eventos
que ocurren en el sistema. Así como
el Filtrado de la información recibida,
el disponer de una base de
conocimiento y mantener todos los
relojes sincronizados.
Acciones a tomar
Una vez detectado, evaluado y
notificado como incidente de seguridad
la respuesta debe de ser rápida; como
primera medida se debe tratar de
contenerlo y evitar que se extienda e

inunde el sistema incrementando los
daños causados. Dependiendo de la
naturaleza del ataque la estrategia de
contención puede ser apagar una
máquina, desconectar un sistema de la
red o deshabilitar algún servicio. La
forma de realizar esta contención debe
estar supeditada al nivel de riesgo
aceptable por la organización y a la
estrategia precisada por la gerencia en
su Plan Forense, el cuál vendrá
definido por una de estas dos
aproximaciones: “Proteger y Proceder”
o “Detectar y Perseguir”.
La información recogida en las
fases de detección y contención puede
ser suficiente para determinar las
causas que originaron el incidente; no
obstante en la mayoría de las
ocasiones las causas serán múltiples y
por tanto habrá que asumir que no
hay un factor único que pueda
identificarse como el origen del
problema. Algunas de estas causas
pueden ser el fallo en la selección y
entrenamiento de los administradores,
la falta de políticas y procedimientos,
la ausencia de apoyo por parte de la
gerencia o el fallo en el despliegue de
actualizaciones.
No se puede solucionar un
problema de seguridad que ha
devenido en el compromiso de un
sistema si no se conoce que ha
ocurrido. Una vez contenido el
incidente, el sistema comprometido
debe de ser aislado para poder ser
analizado bien mediante la
restauración del sistema en un
laboratorio o desconectándolo y
realizando el análisis directamente
sobre el sistema comprometido,
siendo conscientes de que esta forma
de actuación destruirá la fuente
original de la información. Debemos
tener en cuenta que cuando se
detecta un ataque es necesario
verificar todos los sistemas similares
al sistema comprometido. Similar
puede tener diferentes significados
dependiendo de cada entorno de
operación, por ejemplo sistemas que
Perspectiva de las AA.PP.
tengan el mismo rango de direcciones
IP, que pertenezcan al mismo dominio
de confianza o que tengan al menos
un servicio de red en común.
Para analizar un incidente
se debe buscar respuesta
a las siguientes preguntas,
¿qué?, ¿dónde?, ¿cómo?,
¿cuándo?, ¿porqué? y
¿quién?
Tras haber aislado el problema no
deberíamos realizar ninguna tarea
hasta haber obtenido una imagen
completa del sistema comprometido,
lo recomendado sería hacer al menos
dos. Teniendo siempre presente que
en principio desconocemos el grado de
compromiso en el que se halla el
sistema y que por tanto no podremos
confiar en sus herramientas.
A la hora de analizar un incidente
se debe tener presente que se está
buscando respuesta a las siguientes
preguntas, ¿qué?, ¿dónde?, ¿cómo?,
¿cuándo?, ¿porqué? y ¿quién? Se
61
deberá identificar el ataque, cómo se
ha producido, el método de ataque
utilizado y el daño causado. Para ello
tendremos que conocer la forma en
que el atacante obtuvo acceso al
sistema, con total seguridad no lo
habrá logrado en su primera tentativa
y dependiendo de la configuración del
sistema existirán señales de intentos
tales como mensajes de denegación
de acceso, mensajes apuntando a
viejas vulnerabilidades, o el bloqueo
de servicios específicos. La gestión
eficaz del servicio de sincronización
horaria y la adecuada gestión de logs
limitarán el alcance y profundidad de
nuestra investigación.
Pistas del ataque y atacante
Igualmente deberemos conocer el
nivel de acceso logrado por el atacante
a nuestro sistema, ya que en el caso
de no poder determinarlo deberemos
asumir que el atacante pudo acceder a
todos los datos, servicios y programas
del sistema comprometido. Es aquí
donde la Normalización de nuestros
sistemas nos ayudará primero en la
obtención de rastros del incidente y a
fijar después el nivel de restauración a
realizar. El disponer de una base de
sumas de comprobación cifradas de los
ficheros del sistema nos garantizará el
correcto análisis del sistema.
nº 10
mayo 2007