| |
|
|
| |
-
Seguridad Informática - Análisis forense - Investigación
-
Preparación de la investigación
La investigación debe ser precedida por la correspondiente autorización de la dirección de la
organización. Junto con la formulación de la tarea debe ser descrito el objetivo a investigar, tan claramente
como sea posible en el momento de su formulación.
Preservación de las evidencias
La protección de los medios probatorios contra su modificación son de vital importancia para el caso en que
estas evidencias hayan de ser utilizadas en procesos jurídicos. Aquí ha de contemplarse el entorno donde ha
de ejecutarse la investigación y los medios de trabajo.
- Imaging (copia bit a bit de los medios) y captura de
datos
En dependencia del objetivo concreto a investigar se procederá a la captura de informaciones en sistemas activos o
se procederá a duplicar los medios de almacenamiento de datos. Los datos así preservados no serán
siempre evaluados inmediatamente.
- Análisis y valoración de las informaciones
preservadas
El análisis de los medios preservados se realiza posteriormente. Los datos no son solo analizados sino valorados
según su importancia.
- Documentación
Resulta conveniente en cada fase del trabajo forense la confección de una ininterrumpida documentación. En
esta fase se trata de redactar un resumen de los conocimientos, resultados y conclusiones alcanzados.
Que conocimiento pueden ser logrados con la investigación?
Durante la investigación han de desarrollarse diversas actividades como:
- Análisis del ataque
¿Quien tubo acceso?
Ha de determinarse si el intruso actuó con la ayuda de un "insider" interno o desde el exterior.
¿Que hizo el agresor en el sistema?
De la respuesta que se logre a esta pregunta, dependerá el desarrollo posterior de la investigación. Particularmente
se verán influenciadas las medidas a tomar para evitar futuros ataques. Ha de determinarse si datos sensibles fueron vistos,
destruidos o modificados, cuales, si el agresor instaló algún software que le permita acceder al sistema con
posterioridad, como pueden ser "puertas traseras", de tratarse de la modificación de una página Web en
un servidor WWW, seria interesante saber si el intruso dejo algún tipo de información.
¿Cuando ocurrieron los acontecimientos?
Debe determinarse el momento exacto o por lo menos el lapso de tiempo en que se produjo el ataque. Esta información es
de interés cuando sea necesario tomar contacto con los propietarios de otras redes o algún proveedor de servicios
de Internet en el seguimiento de los rastros del intruso. De estas informaciones puede deducirse a partir de cuando el agresor
tuvo la posibilidad de comprometer otros sistemas.
¿Que otros sistemas fueron comprometidos?
Debe determinarse la dimensión de los daños y planificar las medidas de restablecimiento (Recovery), de donde es
necesario el conocimiento de los servidores y redes comprometidas. De determinarse un número elevado de servidores
comprometidos, puede inferirse la existencia de un mayor número de rastros y evidencias.
¿Por que fue agredido precisamente esa red o sistema?
Debe meditarse si el sistema fue agredido preconcebidamente o simplemente a través del escaneo de puertos abiertos. De
tratarse de un Gateway, posiblemente el ataque estaba dirigido a la red que se encuentra tras el.
¿Como pudo el intruso lograr acceso?
La técnica empleada por el agresor es tan interesante para la investigación como los tools utilizados. Esto puede
arrojar luz sobre posibles grupos de agresores. Si, por ejemplo, para la agresión se necesita conocimientos internos de
la organización, puede inferirse que el agresor tuvo un cómplice (Insider). La forma en que se produzca la
agresión puede indicar argumentos sobre como fue posible y donde radican las causas para el propietario de la red.
Con la experiencia lograda del ataque, los administradores pueden impedir que un intruso logre acceso al sistema en la misma
forma
¿La agresión se produjo hace poco tiempo? ¿Que hace ahora?
Si la agresión ocurrió hace poco o el agresor es aún activo, resulta interesante saber cual será
su próximo paso y si volverá a acceder al sistema. De ser así habrá que decidir si se comienza a
reparar los daños o se espera y se sigue observando al intruso.
- Determinación de los daños
¿Que pudo ver el intruso en el sistema?
Para estimar los daños debe identificarse los datos o informaciones que el intruso pudo ver. Esto se refiere no solo
al servidor agredido, sino los sistemas vecinos. Es posible que el segmento de red sea "escuchado" por
"Sniffer" que recoja las claves y otras informaciones sensibles automáticamente, las cuales pueden ser
utilizadas para nuevas agresiones. Es por esto que deben ser cambiadas todas las claves, que pueden haber sido comprometidas.
- Análisis de los tools utilizados por el
intruso
¿Que dejo el agresor a su paso por el sistema?
Es importante encontrar los rastros que el intruso dejo en el sistema (Tools) y análisarlos. Estos pueden brindar indicios
sobre las habilidades y procedencia del intruso. Se utilizaron tools propios, donde se encontraron dichas herramientas con
anterioridad y si se encontraron indicios de otros posibles objetivos de ataque.
¿Que tools fueron utilizados?
De esta forma puede determinarse si este caso tiene similitud con otros. El análisis de las herramientas encontradas
brinda indicios sobre la procedencia y el programador que las creo.
Al analizar los "rotkits" o archivos del sistema trayanizados pueden sacarse conclusiones sobre las intenciones
del agresor. Si por ejemplo, un determinado grupo de direcciones IP debe permanecer oculto, presumiblemente ha de efectuarse
otras acciones desde ellas.
El análisis de datos binarios brinda información sobre el sistema operativo utilizado para compilarlo.
¿Como fueron activados los tools?
La forma en que son activados los tools, ofrece indicios sobre la utilización de scripts. Se dispone de un IDS- u
otro tipo de reporte donde haya podido ser documentado el ataque, puede determinarse si los comandos fueron tecleados o se
empleó un script.
¿En que lenguaje fueron programados los tools?
Este detalle puede ayudar a identificar al agresor. La utilización de lenguajes de programación complejos
reduce el grupo de sospechosos. De tener acceso al código fuente, es posible encontrar rastros en los comentarios,
en designación de variables o errores de sintaxis.
¿Los archivos encontrados tienen similitudes con los archivos que un sospechoso tiene en su sistema?
De haberse encontrado un sospechoso, pueden comparase los archivos binarios encontrados en ambos sistemas. Lo mismo
ocurre con archivos encontrados en otros sistemas atacados.
De la misma forma pueden encontrarse indicios sobre el entorno de desarrollo utilizado (versiones de compilador o
bibliotecas).
- Análisis de los archivos "log"
¿Cuales eventos fueron protocolizados?
Pudieron ser protocolizadas la preparación y realización del ataque así como el acceso a la red?
Existen archivos "log" confiables de Firewall, router o IDS? Si la respuesta es no, por que? Se encuentran en
el sistema comprometido archivos "log" confiables? Existen archivos "History" en el sistema que el
intruso no borro o modifico? La integridad de los archivos "log" es chequeada (por ejemplo con Tribwire o AIDE)?
¿Que informaciones de interés brindan los archivos "log"?
Puede deducirse, a partir de los archivos "log", el ataque y los puntos débiles que lo propiciaron? Puede
determinarse, a partir de los archivos "log", desde que dirección IP se produjo el ataque? Puede determinarse
si desde el sistema comprometido se atacó otros sistemas? Es posible apreciar un modelo o sistematicidad de ataque?
Datos protocolizados de RAS (Remote Access System)
En el caso de que se sospeche que el agresor no accedió al sistema a través del Internet sino desde una estructura
interna, debe asegurarse los archivos de protocolo del RAS. Con un Notebook robado, el cual contiene los loging del RAS de la
organización, es posible acceder a la red. Por esta razón debe protocolizarse los eventos del RAS.
Datos del protocolo de control de acceso al sistema
En el caso que se sospeche de un "insider", o se requiera de un acceso local en el sistema comprometido, producto del
proceso investigativo, deben asegurarse los datos de control de acceso al sistema.
 |
|
Ultima actualisación: Tue, 24 ▪ May ▪ 2011
|
|
|
|
