CON: 3820. GESTIÓN DE INCIDENTES DE SEGURIDAD INFORMÁTICA.

MÓDULO 1 SISTEMAS DE DETECCIÓN Y PREVENCIÓN DE INTRUSIONES (IDS/IPS). UNIDAD DIDÁCTICA 1. CONCEPTOS GENERALES DE GESTIÓN DE INCIDENTES, DETECCIÓN DE INSTRUSIONES Y SU PREVENCIÓN. Conceptos generales. Gestión de incidentes. 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. Aunque un incidente también podría ser la consecuencia de un error o trasgresión (accidental o deliberada) de las políticas y procedimientos de seguridad, o de un desastre natural o del entorno (inundación, incendio, tormenta, fallo eléctrico...). En España, la Ley Orgánica de Protección de Datos define una incidencia como "cualquier anomalía que afecte o pudiera afectar a la seguridad de los datos", en el contexto de los ficheros con datos de carácter personal. Por otro lado, al hablar de “Gestión de Incidentes” hemos de decir, que esta tiene como objetivo resolver cualquier evento que cause una interrupción en el servicio de la manera más rápida y eficaz posible. La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.

Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y software, según el libro de Soporte del Servicio de ITIL un incidente es: “Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de calidad del mismo”. Este sería un ejemplo claro y habitual de “Gestión de incidentes”:

Aquí se muestra un ejemplo del flujo de trabajo en Gestión del Incidente: Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, lo que incluye a las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. siempre que estos servicios se consideren estándar. Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el inicio de una Petición de Cambio que debe ser tratada según los principios de la Gestión de Cambios. Los principales beneficios de una correcta Gestión de Incidentes incluyen:

Mejorar la productividad de los usuarios.

Cumplimiento de los niveles de servicio.

Mayor control de los procesos y monitorización del servicio.

Optimización de los recursos disponibles.

Una base de datos de gestión de configuraciones más precisa pues se registran los incidentes en relación con los elementos de configuración.

Y principalmente: mejora la satisfacción general de clientes y usuarios. Por otro lado, una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales como:

Reducción de los niveles de servicio.

Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando concurrentemente en la resolución del incidente.

Se pierde valiosa información sobre las causas y efectos de los incidentes para futuras restructuraciones y evoluciones.

Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidentes.

Las principales dificultades a la hora de implementar la Gestión de Incidentes se resumen en:

No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan innecesariamente y/u omitiendo los protocolos prestablecidos.

No existe un margen operativo que permita gestionar los “picos” de incidencias por lo que éstas no se registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado.

No están bien definidos los niveles de calidad de servicio ni los productos soportados. Lo que puede provocar que se procesen peticiones que no se incluían en los servicios previamente acordados con el cliente.

Sistemas de detección de intrusos (Intrusion detection systems: I.D.S.) Características básicas de los IDS. Son los sistemas encargados de detectar y reaccionar de forma automatizada ante los incidentes de seguridad que tienen lugar en las redes y equipos informáticos. Para ello, estos sistemas se encargan de monitorizar el funcionamiento de los equipos y de las redes en busca de indicios de posibles incidentes o intentos de intrusión, avisando a los administradores del sistema informático ante la detección de cualquier actividad sospechosa mediante una serie de alarmas e informes.

En la arquitectura de un IDS podemos distinguir los siguientes elementos funcionales básicos:

Una fuente de información que proporciona eventos del sistema o red informática.

Una base de datos de patrones de comportamiento considerados como normales así como de los perfiles de distintos tipos de ataque.

Un motor de análisis encargado de detectar evidencias de intentos de instrucción.

Un módulo de respuesta capaz de llevar a cabo determinadas actuaciones a partir de las indicaciones del motor de análisis.

Por otra parte, un IDS puede utilizar dos modelos de detección:

Detección de un uso defectuoso (misuse): secuencias utilizadas para realizar ataques contra los equipos (exploits), escaneo de puertos, etcétera.

Detección de un uso anómalo: análisis estadístico del tráfico en la red, monitorización de procesos y del comportamiento de los usuarios, con el fin de poder detectar aquellos comportamientos que se puedan considerar anómalos según los patrones de uso registrados hasta el momento: franjas horarias, utilización de puertos y servicios.

Se trataría de este modo, de detectar cambios de comportamiento no justificados en lo que se refiere a ficheros accedidos, aplicaciones utilizadas en el trabajo, cantidad de tráfico cursado en la red etc. Gracias a su módulo de respuesta un IDS es capaz de actuar de forma automática a los incidentes detectados. Las respuestas pasivas se limitan a registrar las posibles intrusiones o usos anómalos, así como a generar informes y alertas dirigidas a los administradores de la red (correos electrónicos, mensajes SMS... ). Por su parte mediante las respuestas activas el IDS podría responder a la situación anulando conexiones o bloqueando el acceso él determinados equipos o servicios de la red para tratar de limitar las consecuencias del incidente. Algunos ejemplos de respuestas activas de un IDS son:

Anular las conexiones TCP inyectando paquetes de reinicio en las conexiones del atacante.

Reconfiguración de los cortafuegos de la red para filtrar el tráfico que pueden estar causando el incidente.

Desconexión automática de servidores y dispositivos de red.

Bloqueo de cuentas o prohibición de la ejecución de determinados comandos

Localización del origen del ataque y notificación a los proveedores de acceso a Internet u organizaciones implicadas.

No obstante, los sistemas IDS también presentan una serie de problemas Y limitaciones como podrían ser la generación de falsas alarmas, ya sean éstas falsos negativos, que se producen cuando el IDS no es capaz de detectar algunas actividades relacionadas con incidentes de seguridad que están teniendo lugar en la red o en los equipos informáticos, o bien falsos positivos, que se producen cuando el IDS registra y genera alertas sobre determinadas actividades que no resultan problemáticas, ya que forman parte del funcionamiento normal del sistema o red informático. Por otra parte, en los entornos conmutados, es decir, en las redes locales que utilizan switches, resulta más difícil monitorizar el tráfico de la red. Por este motivo, en estos casos resulta conveniente la instalación en la red de switches dotados de puertos especiales, conocidos como spanning ports o mirrored ports, que faciliten la captura de todo el tráfico cursado por parte de un sistema IDS. Así mismo, es necesario tener en cuenta la imposibilidad de analizar las comunicaciones cifradas (conexiones que empleen protocolos como SSH, SSL, IPSec...). Por este motivo, resulta conveniente examinar los datos una vez hayan sido descifrados por los equipos destinatarios dentro de la red de la organización. Los sistemas IDS también pueden tener un cierto impacto en el rendimiento de la red y podrían ocasionar una sobrecarga de tareas administrativas si generasen un elevado número de informes y registros de actividad. Entre los principales IDS disponibles en el mercado, podríamos citar SNORT, Real Secure de Internet Security Systems, Sentivist de la empresa NFR, NetRanger de Cisco, etc.

Sistemas de prevención de intrusos (Intrusion prevention systems. I.P.S.). Características básicas. Un sistema IPS (Intrusion Prevention System) es un sistema que permite prevenir las intrusiones. Se trata, por tanto, de un tipo de sistema que pretende ir un paso más allá de los IDS, ya que puede bloquear determinados tipos de ataques antes de que estos tengan éxito. Los IPS buscan anomalías (o comportamientos anómalos) a nivel del sistema operativo, comprueban los módulos cargados por el núcleo, monitorean la actividad del sistema de archivos, buscan RootKits en el sistema, etc. Una intrusión exitosa suele ser acompañada por un conjunto de actividades que los IPS intentar descubrir. Normalmente los intrusos buscan adueñarse o utilizar para algún fin el sistema que atacaron, para esto suelen instalar software que les permita el futuro acceso, que borre sus huellas, keyloggers, software de spamming, virus de tipo botnet, spyware, etc. En la actualidad los IPS incluyen funcionalidades como Firewall y Anti-maleware (anti-virus, anti-spyware, etc.). Los IPS son implementados como agentes instalados directamente en el sistema que protegen. Estos monitorean de cerca al núcleo y los servicios, incluso interceptando llamadas al sistema o APIs. Si un ataque logra atravesar las defensas basadas en red (Firewalls, IPS, IDS, NAC, DDoS Defenses, etc.), el último campo de batalla es el propio sistema operativo de la PC o Servidor del objetivo del ataque, por tanto estos deben estar preparados. Otro elemento que hace importante los HIPS, es el hecho de que el tráfico cifrado no puede ser evaluado por las protecciones basadas en red. Las defensas basadas en Host más avanzadas son los "Host Intrusion Prevention System" y son la última barrera entre el atacante y su objetivo.

UNIDAD DIDÁCTICA 2. IDENTIFICACIÓN Y CARACTERIZACIÓN DE LOS DATOS DE FUNCIONAMIENTO DEL SISTEMA. Los logs de los equipos informáticos (en especial, de los servidores) y de los dispositivos de red facilitan el registro de posibles incidentes y funcionamientos anómalos, la existencia de fallos en la configuración de una aplicación, la posible desconexión de algún dispositivo del sistema, los cambios realizados en la configuración de los equipos, la utilización de recursos sensibles por parte de los usuarios del sistema, etcétera. Además, proporcionan estadísticas que permiten evaluar el rendimiento del sistema informático. No obstante, en algunos casos se podría estar registrando información que podría afectar a la privacidad de los usuarios, por lo que será necesario tener en cuenta las posibles consideraciones desde el punto de vista legal (obligación de informar a los usuarios que se está registrando su actividad en el sistema). En lo que se refiere a los logs del sistema operativo, se podrían configurar para registrar los procesos en ejecución dentro del sistema, los inicios y cierres de sesión por parte de los usuarios, las llamadas al sistema, las aplicaciones ejecutadas por los usuarios, los accesos a ficheros y a otros recursos (impresoras...), los posibles problemas de seguridad (intentos de acceso no autorizado a los recursos o fallos de las aplicaciones), etc. Así, por ejemplo, en los sistemas UNIX se podría utilizar la herramienta "System log", mientras que en los sistemas Windows se puede recurrir al registro de eventos (event log). También será necesario configurar los logs de los dispositivos de red (routers, cortafuegos...), de los servidores y de las aplicaciones instaladas en algunos equipos. Para garantizar la adecuada protección de los logs, será necesario almacenarlos de forma segura en un entorno distinto al del sistema protegido, para evitar que los Intrusos los puedan modificar o eliminar: grabación de los registros en discos WORM (Write Once Rcad More), generación de una copia en papel, etcétera. En algunos casos se puede recurrir a una gestión centralizada de los logs, mediante un servidor de logs que se encargue de guardar copias de lodos los registros enviados por los dispositivos de red y los servidores. Para ello, se podrían utilizar aplicaciones como Syslog para centralizar los registros. De este modo, se refuerza la segundad frente a intrusos que pretendan eliminar su rastro manipulando los logs de los equipos. Además, un servidor centralizado de logs permite conservar los registros durante un mayor periodo de tiempo, lo que puede facilitar el análisis detallado de estos

registros, incluyendo el estudio de la relación entre eventos incluidos en los logs de distintos equipos y dispositivos (elementos de red, de seguridad). Para poder comparar los distintos logs conviene mantener todos los relojes de los equipos y dispositivos sincronizados. Para esto, es de gran utilidad el protocolo NTP (Network Time Protocol, www.ntp.org). En los servidores Web se emplea el formato CLF (Common Lag Format) o el ELF (Extended Log Format), registrando los siguientes datos de cada petición realizada por un cliente remoto:

Dirección IP o nombre de dominio de la máquina remota (cliente) que se conecta al servidor Web.

Identificación remota del cliente.

Nombre de autenticación del usuario.

Fecha y hora de la conexión.

Petición formulada por el cliente (por ejemplo: "GET/index.html HTIP/1.O").

Estado HTIP devuelto por el servidor al cliente.

Número de bytes enviados al cliente.

Agente de usuario (tipo de navegador utilizado): campo ELF.

URL de procedencia (referrer lag): campo ELF. Los administradores de la red tienen a su disposición una serie de herramientas para analizar toda la información registrada en los logs, entre las que se encuentran distintos tipos de filtros y aplicaciones que permiten detectar de forma automática patrones de ataques o situaciones de potencial peligro. En este sentido, se debería considerar el problema de que el exceso de información registrada en el sistema pueda llegar a desbordar a sus administradores, provocando una situación bastante habitual en muchas organizaciones: que los datos de los registros de actividad no sean analizados de forma adecuada.

Por otra parte, suele ser muy recomendable realizar un estudio previo del tráfico en la red para facilitar la posterior detección de situaciones anómalas: consumo de ancho de banda por usuarios y departamentos, patrones horarios del tráfico, servicios y protocolos utilizados. El protocolo de gestión de red SNMP se podría utilizar para recabar parte de esta información de los dispositivos de red. En los servidores Windows se pueden utilizar tres tipos de registros:

Registro de Aplicación: muestra los mensajes, la información del estado y los sucesos generados desde las aplicaciones y servicios instalados en el sistema.

Registro del Sistema: incluye los errores, advertencias y sucesos generados por el propio sistema operativo y sus servicios esenciales.

Registro de Seguridad: muestra los registros de éxito y de fracaso de los servicios auditados, es decir, cuando un usuario intenta acceder a un recurso auditado y se le concede (éxito) o se le deniega (fracaso) el acceso.

Mediante el Visor de Sucesos es posible acceder a la información de estos tres registros.

UNIDAD DIDÁCTICA 3. ARQUITECTURAS MÁS FRECUENTES DE LOS SISTEMAS DE DETECCIÓN DE INTRUSOS. Las arquitecturas de los IDS se han propuesto con el objetivo de facilitar la interoperabilidad y reutilización de módulos, así como la reducción de la complejidad en la gestión y configuración de los IDS. Gracias a la aprobación de protocolos de comunicación específicos, es posible lograr el intercambio de datos entre elementos de distintos fabricantes que pueden formar parte de un IDS. De este modo, se facilita la captura de eventos generados por distintas fuentes, proporcionando una imagen más amplia y detallada de las actividades maliciosas en un determinado entorno. En una arquitectura de IDS se distinguen los elementos Agentes (que se encargan de monitorizar la actividad en el sistema objeto de estudio), los elementos Transceptores (se encargan de la comunicación), los elementos Maestros (centralizan y analizan los datos) y una Consola de Eventos (módulo de interfaz con los usuarios). Las arquitecturas de IDS más importantes son CIDF e IDWG. CIDF (Common Intrusion Detection Framework) es una arquitectura promovida por la Agencia Federal de Estados Unidos DARPA (Defense Advanced Research Projects Agency) y finalizada en 1999, que ha tenido una escasa aceptación comercial. Esta arquitectura está constituida por los siguientes elementos:

Generador de eventos: obtención y descripción de eventos mediante objetos denominados GIDO (Generalized Intrusion Detection Objects).

Analizador de eventos: incorpora los algoritmos de detección de ataques.

Base de datos de eventos: se utiliza el lenguaje CISL (Common Intrusion Specification Language) para expresar los diferentes eventos.

Unidades de respuesta: se encargan de cerrar las conexiones, terminar procesos, bloquear el acceso a los servidores, etc.

Por su parte, la arquitectura IDWG (Intrusion Detection Working Group) propone el formato IDEF (Intrusion Detection Exchange Format) para facilitar el intercambio de información sobre los incidentes de seguridad.

En este caso se distinguen los módulos Sensor, Analizador, Fuente de Datos y Manager:

El Analizador es el componente que analiza los datos recolectados por el Sensor, buscando señales de actividad no autorizada o indeseada.

El Sensor recolecta datos de la Fuente de Datos: paquetes de red, logs de auditoría del sistema operativo, logs de aplicaciones... (información que el IDS emplea para detectar cualquier actividad indeseada o no autorizada).

El Manager es el componente desde el cual se administran los restantes elementos del IDS: se encarga de la configuración de los sensores y analizadores, de la consolidación datos, de la generación de informes, etcétera.

La arquitectura IDWG ha definido un modelo de datos orientado a objetos basado en lenguaje XML para describir los eventos, conocido como IDMEF (Intrusion Detection Message Exchange Format). Así mismo, JDWG prevé dos mecanismos de comunicaciones: el protocolo JAP (Intrusion Alert Protocol), para intercambiar datos de alertas de intrusiones de forma segura entre las entidades de detección, y el protocolo IDXP (Intrusion Detection Exchange Protocol), que permite intercambiar datos en general entre las entidades de detección de intrusiones.

UNIDAD DIDÁCTICA 4. RELACIÓN DE LOS DISTINTOS TIPOS DE IDS / IPS POR UBICACIÓN Y FUNCIONALIDAD. Desarrollando los diferentes tipos de IDS / IPS, iremos especificando la ubicación y funcionalidad de cada uno de ellos. Tipos de IDS. HIDS (Host IDS). Los Host IDS pueden detectar las intrusiones a nivel de host, es decir, a nivel de un equipo informático, observando para ello si se han producido alteraciones significativas de los archivos del sistema operativo o analizando los logs del equipo en busca de actividades sospechosas. Un Host IDS requiere de la instalación de un dispositivo sensor, conocido como “agente”, en equipo informático objeto de monitorización. Este sensor software trabaja a bajo nivel, interceptando las llamadas a las funciones básicas del sistema operativo, Además se encarga de analizar cada actividad y proceso en ejecución dentro del equipo, razón por la que también presenta el inconveniente de disminuir el rendimiento del equipo. Las principales tareas realizadas por un Host IDS son las que se presentan a continuación:

Análisis de los registros de actividad (logs) del núcleo (kernel) del sistema operativo, para detectar posibles infiltraciones.

Verificación de la integridad de los ficheros ejecutables. Para ello, es necesario mantener una base de datos con el estado exacto de cada uno de los archivos del sistema y de las aplicaciones instaladas, a fin de detectar posibles modificaciones de los mismos (integrity check). Herramientas como Tripwire (www. Tripwire.org) facilitan esta función.

Exploración periódica/planificada de programas privilegiados ("setuid" de sistemas UNIX/LINUX).

Auditoría periódica de los permisos asignados a los recursos del sistema.

Búsqueda y evaluación periódica de vulnerabilidades de software conocidas.

Revisión detallada del proceso de instalación de nuevas aplicaciones en el sistema, a fin de poder detectar caballos de Troya u otros códigos malignos.

MHIDS (Multihost IDS). Este tipo de IDS permiten detectar actividades sospechosas en base a los registros de actividad de diferentes equipos informáticos (hosts). Por este motivo, también se les conoce como sistemas "IDS Distribuidos" (DIDS, Distributed IDS). NIDS (Network IDS). Los Network IDS se instalan en una red de ordenadores para monitorizar el tráfico de red en busca de cualquier actividad sospechosa: escaneo de puertos; intentos de explotación de agujeros de seguridad en los servicios instalados en los equipos de la red; ataques conocidos contra determinados protocolos; intentos de ejecución de scripts CGI vulnerables en los servidores; etc. Para ello, un Network IDS trata de detectar el tráfico anómalo que suele acompañar a los intentos de intrusión, analizando para ello el contenido de los paquetes de datos que se transmiten a través de la red de la organización. Entre las distintas situaciones de tráfico anómalo, podríamos citar las siguientes:

Enrutamiento anormal de los paquetes de datos.

Fragmentación de paquetes deliberada.

Utilización de una dirección IP no válida o en desuso en uno de los tramos de red internos (IP Spoofing).

Afluencia de paquetes DNS con identificadores consecutivos, que incluyen la supuesta respuesta a una misma encuesta (situación típica de un ataque de DNS Spoofing).

Invasión de paquetes TCP SYN desde una o varias direcciones (situación típica de un ataque de denegación de servicio del tipo de SYN Flooding).

Invasión de paquetes ICMP o UDP de eco (típicos de ataques como Smurf y Fraggle).

Falsa correspondencia entre las direcciones MAC conocidas y las direcciones IP de los equipos.

Tormentas de tráfico ARP, que podrían revelar un intento de "envenenamiento de las tablas ARP" (situación típica de un ataque de ARP Spoofing).

Uno de los sistemas NIDS más conocidos es SNORT. Este sistema decide qué paquetes de los que circulan por una red resultan sospechosos, empleando para ello una base de datos de reglas que se aplican teniendo en cuenta el contenido y los formatos de cabecera de los paquetes de datos. Además, se pueden descargar nuevas reglas directamente desde bases de datos disponibles en Internet, que permiten catalogar nuevos tipos de incidentes, exploits y vulnerabilidades de sistemas. Tipos de I.P.S.

Honeyputs y honeynets.

Un honeypot es un servidor configurado y conectado a una red para que pueda ser sondeado, atacado e incluso comprometido por intrusos. Se trata, por lo tanto, de un equipo o sistema que actúa a modo de señuelo o trampa para los intrusos. El concepto de sistema trampa ya fue propuesto hace algunos años por Cliff Stoll en su libro Cukoo's Egg. Por su parte, una honeynet (red señuelo) es una red completa que ha sido configurada Y conectada a otras redes para que pueda ser sondeada, atacada e incluso comprometida por intrusos. Los honeypots y honeynets proporcionan varios mecanismos para la monitorización, registro y control de las acciones de los intrusos. De este modo, permiten analizar cómo los intrusos emplean sus técnicas y herramientas para intentar entrar en un sistema o en una red informática (cómo consiguen analizar y explotar sus vulnerabilidades) y comprometer su seguridad (cómo pueden alterar o destruir los datos, instalar programas dañinos o controlar de forma remota los equipos afectados), Además, estas actividades de monitorización de registro se realizan tratando de pasar de forma inadvertida para los intrusos. Por lo tanto, los honeypots y las honeynets entrarían dentro de las aplicaciones tipo know your enemy ("conoce a tu enemigo"), que permiten aprender de las herramientas y técnicas de los intrusos para proteger mejor a los sistemas reales de producción construyendo una base de datos de perfiles de atacantes y tipos de ataques, También podría facilitar la captura de nuevos virus o códigos dañinos para su posterior estudio.

Así mismo, estos sistemas permiten desviar la atención del atacante de los verdaderos recursos valiosos de la red de la organización. En cuanto al diseño de una honeynet, se han propuesto dos arquitecturas conocidas como GenI (año 1999) y GenII (año 2002), siendo la segunda más fácil de implementar y más segura para la organización. Los elementos integrantes de una honeynet, según el esquema anterior, serian varios honeypots (servidores que actuarían de señuelos), un sistema de detección intrusiones en red (NIDS), un servidor de logs, un dispositivo que se haría pasar por cortafuegos (honeywall) y un router. También se podría considerar la posibilidad de incorporar un dispositivo que aplique técnica de bait and switch, según la cual se monitoriza el tráfico procedente de Internet, es decir, aquel que pudiera ser considerado como "hostil" hacia el sistema trampa. En definitiva, podemos considerar que los sistemas basados en señuelos (honeynets y honeypots) ofrecen los siguientes servicios y funciones:

Conexión segura de la red corporativa a Internet.

Captura de datos sobre los intrusos: en los cortafuegos, en el NIDS y en los propios registros (logs) de los honeypots.

Centralización de la información capturada en un servidor de logs, por motivos de seguridad.

Control de las acciones del intruso, ya que éste debe quedar confinado dentro de la honeynet, sin que pueda atacar a otras redes o equipos.

En los honeypots se suelen instalar versiones modificadas del intérprete de comandos (shell en un sistema Unix/Linux o "cmd.exe" en un sistema Windows), como "Comlog", un troyano que remplaza al "cmd.exe" para registrar y reenviar los comandos tecleados por el usuario, así como otras herramientas que permitan registrar las actuaciones de los intrusos (SpyBuddy, keylogger, etcétera). SpyBuddy es una herramienta comercial que permite registrar las teclas pulsadas por el usuario del equipo; monitorizar la creación, acceso, modificación y eliminación de Ficheros y directorios; realizar un seguimiento de los programas que se ejecutan en el equipo; etcétera.

En estos últimos años, se ha propuesto el desarrollo de honeynets virtuales, en una configuración en la que todos los equipos y servicios se ejecutan en un único ordenador, recurriendo para ello a un software de virtualización, como VMWare (www. vmware.com). Este software de virtualización permite la ejecución simultánea de varios sistemas operativos, con distintos tipos de servicios y aplicaciones, en un mismo equipo físico de tal modo que a pesar de compartir los recursos de este ordenador (conocido como host anfitrión), aparenten estar ejecutándose en máquinas distintas e independientes. Una honeynet virtual presenta como ventaja unos menores costes y espacio requerido que en una red física, facilitando la gestión centralizada de todos los servicios y aplicaciones incluidos en la honeynet. Por otra parte debemos tener en cuenta otras consideraciones acerca del uso de estas herramientas, ya que se trata de proyectos de elevado riesgo, debido a las amenazas y tipos de ataques que se van a producir contra los equipos y redes de la organización. Por este motivo, en los equipos y redes señuelo no se deberían incluir datos o información sensible, ni servicios en producción. Además, los posibles ataques contra estos equipos y redes no deberían comprometer a los usuarios y clientes de la red informática de la organización y, mucho menos, podrían afectar a terceros. Para ello, es necesario establecer las medidas de control y bloqueo de los posibles ataques e intentos de intrusión llevados a cabo contra redes y equipos de terceros desde los equipos que hayan sido comprometidos en la honeynet, ya que de lo contrario la organización podría incurrir en responsabilidades legales por los daños ocasionados a terceros desde sus propios equipos y redes informáticas. Otra cuestión legal que se podría contemplar surge en torno a la discusión de hasta qué punto es lícito emplear estas herramientas para espiar a los intrusos, sin que estos hayan sido advertidos previamente de que sus actividades están siendo registradas por la organización. Para concluir este apartado, podemos citar algunos ejemplos de herramientas y proyectos de interés relacionados con los honeypots y las honeynets. Así, podemos encontrar en Internet aplicaciones que permiten simular determinado servicios para registrar los posibles intentos de ataque e intrusión, como BackOfficer Friendly Specter, Honeyd, Decoy Server de Symantec, Deception Toolkit, etc. Por su parte, el proyecto HoneyNet (www.honeynet.org) se remonta a Junio del año 2000, con el objetivo de "estudiar las técnicas, tácticas y motivaciones de la

comunidad de atacantes y compartir las lecciones aprendidas". En la actualidad, este proyecto está integrado por profesionales de distintos perfiles y áreas de conocimiento: informáticos, psicólogos, ingenieros de redes, etcétera.

UNIDAD DIDÁCTICA 5. CRITERIOS DE SEGURIDAD PARA EL

ESTABLECIMIENTO DE LA UBICACIÓN DE LOS IDS / IPS.

Para elegir la ubicación del IDS / IPS hay que valorar el grado de interoperabilidad con el resto de nuestras protecciones de red. Existen varias posibilidades y cada una tiene distintas ventajas e inconvenientes.

En la red LAN local, detrás del cortafuegos, es el lugar más común, ofrece la mejor protección frente a las amenazas externas e internas. Al escuchar el cable local, podemos detectar la actividad interna de otros usuarios (como la actividad entre estaciones de trabajo o el uso ilícito de un programa). También refuerza el cortafuegos, detectando una actividad sospechosa que de alguna manera ha conseguido pasar los filtros del cortafuegos. De hecho, se pude utilizar un IDS para probar un cortafuegos y comprobar lo que permite pasar.

Sin embargo, este sistema generará muchas alertas basadas en el tráfico de red de Windows, por lo que debemos estar preparados para realizar muchos ajustes en esta área. Así mismo, si nos encontramos en una LAN conmutada, necesitaremos la capacidad de reflejar todos los puertos sobre un puerto monitor para poder permitir al IDS escuchar todo el tráfico LAN.

En el segmento DMZ, podemos colocar un sensor Snort en la DMZ para registrar la actividad que entra en los servidores públicos. Como esos servidores son los más expuestos y normalmente representan recursos valiosos, es buena idea supervisarlos con un IDS. El problema de esta configuración es ordenar todas las alertas. Aunque todas ellas puedan ser alertas v salidas, con el nivel de ataque de tráfico general actual en Internet, cualquier IP pública es atacada de forma aleatoria todos los días. Reaccionar ante ello intentando localizar dichas alertas sería excesivo y contraproducente.

Por lo tanto, ¿cómo podemos saber qué alertas son sólo gusanos que están atacando a nuestro servidor y qué alertas están realmente avisándonos de un intruso real? Una forma de hacerlo es reduciendo el número de firmas a un pequeño número que solo se activen si el host está realmente comprometido, por ejemplo, reglas específicas a las aplicaciones que se están ejecutando en el host, como MySQL.rules, web-iis.rules o reglas relacionadas con la administración de conexiones.

Entre el ISP y el cortafuegos. Esta configuración filtrará todo el tráfico entrante y saliente de la LAN y DMZ. Lo bueno es que capturará todos los ataques tanto a los servidores públicos como a la LAN interna. Lo malo es

que no podremos ver ningún tráfico interno y el volumen general de las alertas puede ser bastante alto, debido al tráfico de ataque general subyacente.

Igual que en el ejemplo anterior, se puede probar a reducir las alertas y dejar solo las que realmente van a mostrar algún problema para este segmento. Así mismo, al situarlo entre el sensor ISP y el cortafuegos, puede crear un cuello de botella y un punto de errores para nuestro tráfico de red.

Todas las formas pueden ser válidas para utilizar IDS / IPS y no hay razón para que no podamos seguir las tres, siempre que tengamos el hardware y el tiempo necesario para hacerlo.

MÓDULO 2. IMPLANTACIÓN Y PUESTA EN PRODUCCIÓN DEL SISTEMA. UNIDAD DIDÁCTICA 1. ANÁLISIS PREVIO DE LOS SERVICIOS, PROTOCOLOS, ZONAS Y EQUIPOS QUE UTILIZA LA ORGANIZACIÓN PARA SUS PROCESOS DE NEGOCIO. El nivel de seguridad y la gestión ofrecida por los Sistemas de Detección de Intrusiones, los hace casi imprescindibles en muchas de las organizaciones que cuentan con importantes infraestructuras de red. Como ya se apuntó anteriormente, estos sistemas, aunque tienen muchas ventajas, no son perfectos. Por otra parte, muchos administradores carecen de los conocimientos adecuados para aprovechar al máximo sus características. Esto hace que la implementación de estos sistemas requiera un proceso previo de planificación, preparación, fase de pruebas, y formación especializada. Cada solución debe adaptarse a las necesidades particulares de cada caso, analizando entre otras características, las políticas de la organización, el nivel de desarrollo y los recursos de red. Los requisitos de sistema de los IDSs dependen de los objetivos y recursos de cada organización. Por lo general, suele ser recomendable alcanzar una solución basada en el uso conjunto de IDS de red (NIDS) y de "host" (HIDS). Por otra parte, si se acomete la implementación de forma escalonada, añadiendo de forma progresiva cada IDS, los propios administradores irán adquiriendo más experiencia con cada adición. Normalmente se empieza con la instalación de IDS basados en red, más sencillos de instalar y gestionar. Posteriormente, se instalan IDS basados en “host” en las máquinas críticas. Una planificación de estas características debe completarse con el uso regular de analizadores de vulnerabilidades sobre los IDSs y otros elementos de seguridad. De esta manera, se ayuda a mantener la estabilidad y confianza de estos mecanismos. En caso de implementar sistemas o redes trampa, es necesario contar con personal especializado en temas de seguridad y redes, y ubicar dichos sistemas en entornos altamente protegidos. Además, hay que asesorarse previamente en temas legales relacionados con estos elementos. A continuación, se describirán las características más comunes del establecimiento de detectores de intrusiones basados en red y en máquina.

Sistemas de Detección de Intrusiones de red. Los agentes de un IDS basado en red monitorizan el tráfico de red para enviar los datos al motor de análisis. Estos elementos de monitorización pueden colocarse en distintos puntos de la arquitectura. Uno de los objetivos de los agentes es el de no ser reconocido por atacantes, así como no interferir en el rendimiento de la red. Para ello, se suelen conectar al medio utilizando dispositivos de escucha. La interfaz de red dedicada a la monitorización se configura de forma que no tenga dirección IP. En algunas ocasiones, estos dispositivos se conectan a la red mediante un cable de sólo recepción o un “network tap” (dispositivo de escucha de red). El abanico de productos de detección basados en red es muy extenso. Entre ellos destaca por su popularidad snort, un potente detector de intrusiones de red, escrito en código abierto, basado en reglas, que incorpora algunas funciones de detección de anomalías. Algunos ejemplos más de productos de este tipo son: Bro, escrito por Vern Paxson; Firestorm, de John Leach y Gianrú Tedesco; Tiny Personal Firewall (cortafuegos personal con capacidades de IDS), de Tiny Software Inc; o el IDS híbrido (basado en máquina y en red) Prelude, distribuido bajo licencia GPL y desarrollado por Yoann Vandoorselaere. A continuación, se describirán las localizaciones más comunes en las que se puede implementar un NIDS. Cada una tiene sus propias ventajas e inconvenientes. Delante del cortafuegos externo. Colocar los agentes delante del cortafuegos externo, permite:

Monitorizar el número y tipo de ataques dirigidos contra la infraestructura de la organización.

Detectar ataques cuyo objetivo es el cortafuegos principal. Por otra parte, esta posición también presenta algunos inconvenientes:

No permite detectar ataques que utilicen en sus comunicaciones algún método para ocultar la información, como algoritmos de encriptación.

En esta localización suele haber gran cantidad de tráfico de red. Un detector de intrusiones mal diseñado puede saturarse, descartando parte de la información que percibe, si no ha sido bien diseñado.

Una situación como esta no ofrece ninguna protección. El NIDS puede convertirse en un blanco fácil si algún atacante logra identificarlo.

Detrás del cortafuegos externo. Esta localización, situada entre Internet y la red interna, se denomina DMZ (Zona Desmilitarizada). Se utiliza para proporcionar servicios públicos sin tener que permitir acceso a la red privada de la organización. En esta subred se suelen ubicar los servicios principales de la infraestructura (servidores HTIP, FTP, SMTP, DNS, etc.). Normalmente está protegida por cortafuegos y otros elementos de seguridad. Algunas de las ventajas de este caso son:

Se monitorizan intrusiones que logran atravesar el cortafuegos principal.

Se pueden detectar ataques dirigidos contra los servidores que ofrecen servicios públicos situados en esta subred.

En caso de no detectar ataques con éxito, pueden reconocer algunas consecuencias de los mismos, como intentos de conexiones salientes, realizadas desde los servidores comprometidos.

La identificación de los ataques y escaneos más comunes permite mejorar la configuración del cortafuegos principal.

A continuación se enumeran algunos de las desventajas de esta localización:

Al igual que en el caso anterior, no permite identificar ataques que utilicen métodos para ocultar la información contenida en sus comunicaciones, como algoritmos de encriptación.

La cantidad de tráfico existente normalmente en este segmento de red, puede hacer que el NIDS no pueda analizarla toda, descartando datos. Es importante diseñar un sistema capaz de responder ante situaciones críticas.

La seguridad del NIDS mejora con la inclusión del cortafuegos que lo separa de la red exterior. Sin embargo, esto no excluye de tomar medidas adicionales para evitar que pueda ser comprometido por atacantes.

Redes principales. Cuando se monitoriza el tráfico de red en las redes con mayor actividad se obtienen estas ventajas:

Al haber más cantidad de tráfico, hay también más posibilidades de encontrar posibles ataques. Este hecho se cumple siempre que la cantidad de tráfico no supere la capacidad del NIDS.

Se pueden detectar ataques producidos desde dentro de la propia red, como los realizados por personal interno.

Las desventajas relacionadas con esta posición son, entre otras:

Al igual que en los casos anteriores, esta localización no permite detectar ataques que utilicen algoritmos de encriptación en sus comunicaciones.

No pueden evitar problemas asociados al uso de conmutadores en la red. Las características de estos dispositivos podrían impedir la monitorización de los miembros de la red.

Esta situación hace que estos sistemas sean especialmente vulnerables ante ataques provenientes, no ya del exterior, sino del interior de la propia infraestructura. Es vital tener este aspecto en cuenta a la hora de implementar un detector de intrusiones en esta localización.

Subredes de valor crítico. A veces, los servidores y recursos más importantes de una red son situados en una subred separada de la red principal mediante dispositivos como cortafuegos. Para protegerlos debidamente, es necesario implementar detectores de intrusiones basados en red en estas subredes privadas. Algunas de las ventajas de hacer esto son:

Detectar ataques realizados contra elementos críticos de la red.

Dedicar especial atención a los recursos más valiosos de la infraestructura.

A continuación, se enumeran algunas desventajas del uso de esta opción:

Como ya se comentó en las situaciones anteriores, este caso no permite detectar ataques que utilicen algoritmos de cifrado en sus comunicaciones.

No evitan problemas de monitorización relacionados con el uso de conmutadores.

No están estratégicamente bien situados ante ataques de origen interno. Máquinas. Otra de las posibles formas de instalar este tipo de sistemas es en las propias máquinas, convirtiéndolas rastreadores de red. Los IDSs basados en red implementados de esta forma se denominan IDS de nodo de red (NNIDS) ("Network Node IDS"). La mayoría de los productos de detección basados en red nombrados antes se pueden implementar de esta forma. Cualquier detector basado en red, que permita la instalación de uno de sus agentes en una máquina, puede ser utilizado de esta forma. Esta localización proporciona ventajas únicas:

Se evitan los inconvenientes de la encriptación de las comunicaciones, presentes en las localizaciones anteriores. El NNIDS deja de recibir cifrado el tráfico originado o destinado a la máquina en la que está instalado. No obstante, seguirá percibiendo cifradas el resto de las comunicaciones.

Es una forma de solventar problemas derivados del uso de conmutadores. Fuentes de información basadas en red este tipo de dispositivos dificultan la monitorización del tráfico red, realizando tareas de encaminamiento, cosa que no hacen los concentradores. Situar un detector en una máquina permite al menos, examinar sus propias comunicaciones.

Por otra parte, este enfoque también tiene inconvenientes:

La visión del sistema de detección está claramente limitada tanto por la situación de la máquina, como por la arquitectura de la red. Por ejemplo, si se utilizan conmutadores, sólo puede analizar el tráfico relacionado con la máquina anfitriona. No obstante, si se hace uso de concentradores,

analizaría además el tráfico del resto de los miembros de la red, actuando como un rastreador.

El NIDS está compartiendo los mismos recursos que la máquina que monitoriza. Esto reduce los recursos de la misma, afectando evidentemente a su rendimiento final.

Que la máquina anfitriona sea comprometida puede tener graves consecuencias. El detector no sólo perdería toda eficacia, sino que además, podría ser controlado por el atacante para llevar a cabo sus fines. Obtener información sobre la infraestructura de la organización, o enviar falsas alarmas que distrajeran la atención del responsable de seguridad, son sólo algunos ejemplos de lo que un intruso podría hacer en dicha situación.

Sistemas de Detección de Intrusiones de máquina. Como se comentó al principio del capítulo, en una estrategia de implementación general, los detectores de intrusiones basados en máquina ("host") se suelen instalar después de los basados en red. Esto se hace así ya que, dadas sus características, son más complicados de instalar. Este tipo de sistemas necesita ser configurado de forma individual en cada máquina, y utiliza como fuente de datos la información obtenida del sistema. La mayoría de los detectores de intrusiones incluyen, entre otras funciones, mecanismos de verificación de integridad de archivos. Esto les permite, mediante el uso de algoritmos de cifrado como funciones resumen, reconocer cambios en los ficheros más importantes del sistema. Aunque la situación ideal es la de contar con uno de estos sistemas en cada una de las máquinas de la red, lo cierto es que el procedimiento más extendido a seguir es el de instalarlos primero en los servidores más importantes. Una vez que los responsables se han acostumbrado a esta situación, se pueden ir implementando en el resto de los equipos. Es muy importante que los administradores de estos sistemas se acostumbren a la forma de trabajar de estos sistemas, afinando la configuración para adaptarla a su situación particular, y aprendiendo a distinguir entre las falsas alarmas y los verdaderos problemas de seguridad. Los informes emitidos por los detectores basados en máquina deben ser revisados de forma periódica. No siempre es posible ir examinando individualmente cada detector. Por ello, muchos productos facilitan mecanismos de centralización de

registros, que permiten gestionar las alarmas de una forma más cómoda, rápida y eficiente. Algunos de los productos más conocidos, que se utilizan como detectores de intrusiones basados en host son: GFI LANguard S.E.L.M, de GFI Software Ltd.; Tripwire, LogCaster, de Enterprise International; o el ya mencionado IDS híbrido, Prelude. Algunas de las ventajas del uso de estos sistemas son:

Trabajan con el sistema de ficheros, y con registros de sistema operativo locales, por lo que pueden detectar ataques que no identificados los detectores basados en red.

Su especialización les otorga ventaja a la hora de detectar ataques específicos de los sistemas que monitorizan.

Su posición privilegiada les permite identificar con precisión los elementos involucrados en un ataque, tales como procesos de sistema, ficheros o nombres de usuario.

Dada su naturaleza, este tipo de sistemas no se ve afectado por un entorno de red con conmutadores.

Alarmas. Uno de los apartados más importantes de los IDSs es el relativo a las alarmas. Elaborar una arquitectura de los mecanismos de alarma y procedimientos de respuesta frente a ataques, antes de implementar estos sistemas, puede evitar muchos problemas en caso de ataque. Estos sistemas permiten enviar una alarma de muchas formas: añadiendo un evento en los registros de auditoría o sistema, un mediante correo electrónico, utilizando protocolos de gestión de red (SNMP), a través de mensajes a móviles ("Short Message Service" (SMS)), etc. Es recomendable dejar pasar unas semanas, antes de activar los mecanismos de alarma de un detector de intrusiones. Ese tiempo se debe dedicar para ajustar la configuración a cada escenario particular, reduciendo la aparición de falsas alarmas. Por otra parte, si se configuran respuestas automáticas que permitan responder ante acciones hostiles, como por ejemplo, bloqueando la dirección origen del

atacante, es preciso seguir de cerca su funcionamiento, para impedir que un intruso se aproveche de estas funciones. De lo contrario, un atacante podría "falsificar" su dirección origen, utilizando las de otras entidades, que podrían incluso pertenecer a clientes de la empresa atacada o de la propia red privada, provocando evidentes problemas. Para asegurarse de que las alarmas llegan a su destino, se suelen utilizar técnicas de redundancia; se envía la misma alarma utilizando distintas métodos de comunicación. Este tipo de medidas se toma en casos de alarmas de nivel crítico.

UNIDAD DIDÁCTICA 2. DEFINICIÓN DE POLÍTICAS DE CORTE DE INTENTOS DE INTRUSIÓN EN LOS IDS/IPS. Asegurar un sistema no sólo consiste en tomar las medidas necesarias para protegerlo ante ataques u otros problemas, sino estar al tanto de los aspectos legales relacionados con el tema. La implementación de un Sistema de Detección de Intrusiones en muchas ocasiones implica el cumplimiento de una serie de requisitos impuestos por la Ley. Cumplir con estas obligaciones permite perseguir a los culpables mediante procesos legales o judiciales. Los registros e informes proporcionados por un detector de intrusiones pueden ser requeridos como pruebas que ayuden a localizar y condenar a los responsables. Desgraciadamente, los sistemas legales de muchos países no se han adaptado a la misma velocidad que el desarrollo de las tecnologías, dejando vacíos que permiten a los criminales delinquir con total impunidad. En este capítulo se hará un breve repaso por el estado actual de los sistemas legales del mundo, para centrarse posteriormente en el marco legal de Europa y en el de España. Se comentarán los aspectos legales relacionados con delitos informáticos, y más concretamente, los relacionados con los Sistemas de Detección de Intrusiones. Sistemas legales en el mundo. Actualmente, los sistemas legales más utilizados en el mundo se pueden clasificar en seis tipos: derecho civil, "common law”, derecho consuetudinario, derecho musulmán, derecho talmúdico y derecho mixto. El "Derecho Mixto" es una combinación de dos o mas sistemas jurídicos y no a un tipo de sistema jurídico. Derecho civil. Este sistema legal es el utilizado por aquellos países basados en el sistema legal romano. Profieren gran importancia al derecho escrito, y adoptan una codificación sistemática de su derecho común. Por otro lado, también se encuentran en esta categoría aquellos países, generalmente de derecho mixto, que sin haber recurrido a la técnica de la ley codificada, poseen suficientes elementos de construcción jurídica romana que permiten considerarlos como adscriptos a la tradición civilista.

También se incluyen en este tipo los países en los que, a pesar de que no contar con importante influencia romana, practican un derecho, codificado o no, que reposa en una concepción del rol de la ley similar a ésa de los países de tradición civilista “pura”. Un ejemplo de este caso es el de los países de tradición escandinava. Este es uno de los sistemas legales más practicados en todo el mundo. Entre los que lo han adoptado se encuentran muchos países europeos (España, Francia, Alemania o Italia entre otros), así como gran parte de los países de Sudamérica (como Venezuela, Argentina, Brasil) y América Central (como México, El Salvador, Guatemala). "Common law". Otro de los sistemas legales más practicados en todo el mundo es el "Common law''. En esta categoría entran aquellos países en los cuales el derecho reposa técnicamente, al menos en lo esencial, sobre los conceptos y los modos de organización jurídica del "common law” británico. Este modelo otorga gran importancia a la jurisprudencia, y no a la ley como medio ordinario de expresión del derecho común. En consecuencia, la mayoría de países adscritos a este sistema legal están más o menos relacionados con la tradición británica. Entre los países que utilizan este sistema además de Inglaterra están Estados Unidos, Canadá, Irlanda, Australia o Nueva Zelanda. Derecho consuetudinario. Aunque actualmente no existen países cuyos sistemas legales puedan sean enteramente consuetudinarios, el derecho consuetudinario juega un importante papel en gran número de países de derecho mixto. Este sistema es practicado en algunos países africanos. También es aplicado, con diferentes condiciones, en países como China e India. Derecho Musulmán y Derecho Talmúdico. Estos son sistemas autónomos de derecho religioso propiamente dicho. No hay separación entre el estado y la religión, al contrario que en el derecho canónico. Este último, aunque influenciado por dogmas religiosos, es producto de la elaboración humana es uno de los componentes de la tradición civilista.

Con excepción de Afganistán o las Islas Maldivas, los países que se rigen por este sistema lo utilizan en conjunción con algún otro (como "Common Law" o Derecho Civil). La mayoría de estos países se encuentran en oriente medio. Derecho Mixto. Se engloban en esta categoría aquellos países donde dos o más sistemas se aplican de manera acumulativa o de interacción. También pertenecen a la misma aquellos países en los cuales hay una yuxtaposición de sistemas, dado que los mismos se aplican simultáneamente a áreas más o menos diferenciadas. Territorios no independientes. Por último, cabe mencionar cierto número de sistemas aplicados en una serie de territorios no independientes, que por diversos motivos no están vinculados al sistema jurídico de la metrópolis. Estos sistemas, bien han adquirido o mantenido características distintas dentro del nombre federal o unidad política a la cual pertenece. Otros sistemas. Derecho penal. Además de los sistemas antes mencionados, otra parcela importante en este caso es el Derecho penal, cuyo contenido es un catálogo de normas que protegen los valores que una sociedad considera más importantes, así como las sanciones que se pueden imponer para el caso de incumplimiento. Por tanto, el Derecho penal contiene una lista de delitos y sus penas. Esta lista de delitos y penas puede provenir de un sistema de codificación, como en todo el mundo occidental, o de textos incluso religiosos (El Corán) pero es importante señalar que los derechos humanos y libertades fundamentales tienen gran trascendencia en este campo, por lo que rigen principios universales no aplicables a otras ramas del Derecho, como el principio de legalidad, que exige que para que se produzca un delito, debe, forzosamente, existir una Ley previa que defina dicho delito. Debido a esta razón, la costumbre no es fuente de este Derecho, ni siquiera en los países de Derecho consuetudinario o de Common Law. Derecho procesal. Si los análisis de la detección de intrusiones tienen como destino servir de prueba en un procedimiento judicial, deberán asimismo tenerse en cuenta los diferentes requisitos legales para que sean válidas y eficaces la obtención, conservación y

presentación de las pruebas en juicio. En este aspecto, cada país tiene sus reglas, no pudiéndose establecer en este caso categorías comunes. Situación en Europa. En lo que respecta a la situación legal sobre delitos informáticos, los países pertenecientes al Consejo de Europa acordaron el 21 de noviembre de 2001 el "Convenio sobre la Ciberdelincuencia", en el que también participaron los Estados Unidos. Este documento fue firmado por los representantes de cada país, aunque su eficacia depende de su posterior refrendo por los órganos nacionales de cada país firmante. Este documento sirvió para definir los delitos informáticos y algunos elementos relacionados con éstos, tales como “sistemas informáticos”, “datos informáticos” o "proveedor de servicios". Los delitos informáticos fueron clasificados en cuatro grupos descritos a continuación:

Delitos contra la confidencialidad, la integridad y la disponibilidad de los datos y sistemas informáticos.

- Acceso ilícito a sistemas informáticos. - Interceptación ilícita de datos informáticos. - Interferencia en el sistema mediante la introducción, transmisión,

provocación de daños, borrado, alteración o supresión de estos. - Abuso de dispositivos que faciliten la comisión de delitos.

Delitos informáticos. - Falsificación informática que produzca la alteración, borrado o supresión

de datos informático que ocasionen datos no auténticos. - Fraudes informáticos.

Delitos relacionados con el contenido. - Delitos relacionados con la pornografía infantil.

Delitos relacionados con infracciones de la propiedad intelectual y derechos afines.

Los delitos relacionados con los ataques detectados por los Sistemas de Detección de Intrusiones estarían principalmente contemplados en la primera categoría: "Delitos contra la confidencialidad, la integridad y la disponibilidad de los datos y sistemas informáticos".

En el “Convenio sobre la Ciberdelincuencia” se encomienda a cada parte que tome las medidas necesarias para tipificar como delito en su derecho interno cada uno de los apartados descritos en cada categoría. Situación en España. A pesar de que en España se están haciendo progresos en el plano legal para regular los delitos relacionados con las tecnologías de la información, lo cierto es que la situación aún es muy precaria. En este apartado se hará referencia a los principales elementos relacionados con el marco legal que tienen que ver con los delitos informáticos, intentando destacar aquellos temas relacionados con los Sistemas de Detección de Intrusiones. Legislación. Se entiende por delito informático todo ilícito penal llevado a cabo a través de medios informáticos y que está íntimamente ligado a los bienes jurídicos relacionados con las tecnologías de la información o que tiene como fin estos bienes. España cuenta con un Código Penal en el que no existe ningún título que se refiera específicamente a delitos informáticos. No obstante, se pueden encontrar algunos tipos penales adaptables a los definidos en el “Convenio sobre la Ciberdelincuencia” Delitos informáticos y el Código Penal. Los tipos penales definidos en el Convenio del Consejo de Europa se pueden encontrar reflejados en el Código penal español de 1995 (Ley Orgánica 10/1995, de 23 de Noviembre). De esta forma se extraen las siguientes conductas delictivas, en las que los datos o sistemas informáticos son instrumentos de comisión del delito o el objeto del delito:

Delitos contra la confidencialidad, la integridad y la disponibilidad de los datos y sistemas informáticos.

Delitos informáticos.

Delitos relacionados con el contenido.

Delitos relacionados con infracciones de la propiedad intelectual y derechos afines.

Una vez más, se debe mencionar que la mayoría de los actos delictivos relacionados con un detector de intrusiones están recogidos en el primer grupo. A pesar de recoger muchos de los casos descritos por el Consejo de Europa, algunas conductas como el "Spam'', escanear puertos, la apología del terrorismo a

través de Internet o el blanqueo de capitales no están contemplados entre los delitos tipificados en nuestro Código Penal. Debido a esta razón, su persecución penal se realiza conjuntamente con los delitos a los que los ordenadores o las redes sirven como la herramienta para su comisión, no siendo considerados delitos autónomos en sí mismos. Delitos informáticos y el C.N.P. Los delitos informáticos contemplados en España, según la Brigada de Investigación Tecnológica del Cuerpo Nacional de Policía, se pueden clasificar en base a su correspondencia en el Código Penal. El texto que acompaña a cada artículo es una explicación del delito, y no se corresponde con su contenido.

Ataques que se producen contra el derecho a la intimidad.

Infracciones a la Propiedad Intelectual a través de la protección de los derechos de autor.

Falsedades.

Sabotajes informáticos.

Fraudes informáticos.

Amenazas.

Calumnias e injurias.

Pornografía infantil.

Legislación adicional. Existe un cuerpo legislativo, fuera del ámbito penal, que pretende regular el aspecto de la Sociedad de la Información. Alguna de estas leyes ha sido especialmente formulada con ánimo de proteger la intimidad y privacidad de los ciudadanos y sus datos. Conocer y cumplir los requisitos descritos en las mismas hace posible la adopción de comportamientos útiles legalmente en caso de delito.

Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (LOPD). Supone una modificación importante del régimen sobre protección de datos de personas físicas contenido hasta entonces en la extinta LORTAD. Esta norma por introduce en el marco jurídico unos valores sobre la defensa de la intimidad y privacidad de los ciudadanos y consumidores, a los que reconoce un conjunto de derechos.

No obstante, la ambigüedad y falta de precisión de ciertos términos y situaciones, dificulta su aplicación.

Ley 34/2002, de 11de julio, de Servicios de la Sociedad de la Información y Comercio Electrónico (LSSICE). Esta ambiciosa Ley supone la primera regulación legal que con carácter general se dicta en España para el entorno de Internet. Aunque su principal objetivo consiste en aplicar la Directiva 200/31/CE (Directiva del Comercio Electrónico). También define otros factores relacionados con la "Sociedad de la Información” como las obligaciones de Servicio Universal, o la legalidad o ilegalidad de los actos que cualquier particular puede realizar en la Red.

Real Decreto Legislativo 1/1996, de 12 de abril (BOE 22-4-1996), por el que se aprueba el texto refundido de la Ley de Propiedad Intelectual. Real Decreto Legislativo 1/1996, de 12 de abril (BOE 22-4-1996), por el que se aprueba el texto refundido de la Ley de Propiedad Intelectual.

Real Decreto Legislativo 14/1999, de 17 de septiembre, sobre Firma Electrónica. Reconoce la eficacia jurídica de la firma electrónica y las condiciones para prestar servicios de certificación en España. Actualmente se está tramitando una nueva Ley de Firma Electrónica, que se halla en fase de Proyecto de Ley en esta fecha.

Intrusiones y la Legislación española. Las intrusiones, o accesos no consentidos, tienen cierta consideración por parte del Código penal español, el cual contempla dos casos concretos:

"Hacking" directo, mero acceso no consentido. Se define así a las intrusiones perpetradas con el único fin de vulnerar un mecanismo de seguridad que permita el acceso a sistemas informáticos o redes de comunicación electrónica de datos. El intruso sólo accede al sistema y sale, demostrando el fallo de seguridad del mismo, sin ánimo delictivo en esta conducta. El mero acceso y la mera permanencia no autorizada, actualmente no está castigada por el Código penal español, a diferencia de lo ocurrido en otros países, como Francia, que sí castiga y persigue este caso.

"Hacking” indirecto. Consiste en el acceso no consentido a un sistema informático o redes de comunicación electrónica de datos con el fin de cometer un delito. En este caso la intrusión se concibe como un medio necesario para cometer el delito final cuyo móvil guía al sujeto desde el principio. En este caso el acceso queda subsumido en el delito finalmente

cometido (descubrir secretos de empresa, vulnerar el habeas data, interceptar las comunicaciones, producir daños, etc.).

Por lo tanto, y según lo descrito, un mero acceso no consentido no constituye un delito en España. Cuerpos especiales. En España se han creado organismos especiales de investigación tanto en el Cuerpo Nacional de Policía, como la Brigada de Investigación Tecnológica, como en la Guardia Civil, con el Grupo de Delitos Telemáticos. Además, se les ha provisto de medios técnicos cada vez más avanzados para poder ejercer su labor. Los mismos medios utilizados por los delincuentes para cometer sus delitos sirven también a los especialistas para establecer medidas de seguridad y obtener pruebas que los identifiquen e inculpen. Necesidades y deficiencias. Como ya se comentó al principio del apartado sobre la situación en España, el marco legal español, a pesar del Código penal actual y las unidades especiales para el control de los delitos informáticos, presenta importantes limitaciones a la hora de perseguir a los delincuentes informáticos. La rapidez con que se desarrollan las nuevas tecnologías y la posibilidad de actuar desde cualquier parte del mundo, hace de los delitos informáticos uno de los retos más importantes a los que se enfrentan las autoridades legales y judiciales de los países más desarrollados. A continuación, se muestran una serie de factores que complican la labor de estas entidades:

- Determinar la jurisdicción competente.

- Delitos cometidos desde fuera de España, provenientes de un país en el que no exista regulación sobre el tema.

- Dificultad para obtener pruebas fehacientes que inculpen al delincuente.

- Dificultad para identificar al autor del delito. No hay que olvidar que las

técnicas de ocultación de dirección IP por parte de un intruso pueden hacer imposible su localización.

- Falta de adaptación de los organismos legislativos a los rápidos cambios y

nuevas situaciones provocadas por la aparición de las nuevas tecnologías. Y necesidad de mayor cooperación entre distintos países para abordar el

tema. Esto reduciría el ámbito de actuación de muchos delincuentes que se aprovechan de la situación actual.

Políticas de seguridad para evitar intrusiones. Una Política de Seguridad define lo que se permite y lo que se niega en un sistema. Hay dos filosofías básicas detrás de cualquier política de seguridad:

1. Prohibitiva. En esta política todo aquello que no está expresamente permitido es negado.

2. Permisible. En esta política todo lo que no está negado expresamente es

permitido. Generalmente, un lugar que es más paranoico sobre seguridad toma la primera opción. Se usara una política que detalla exactamente los funcionamientos u operaciones que se permite en un sistema. Cualquier otra operación que no esté detalla en éste documento de la política será considerada como ilegal dentro del sistema. Es claro que este tipo de políticas se prestan bien para un ambiente militar, y estos tipos de políticas son raros en establecimientos civiles. La segunda filosofía está más ligada al espíritu de la informática. Los usuarios de computadoras siempre han intentado usar el potencial de las computadoras al máximo, aun cuando esto signifique violar las reglas. Esto era aceptable con tal de que el trabajo se realizara bien y completo en el tiempo necesario, y nadie resultaba afectado. Desgraciadamente, esta filosofía no funciona bien en los ámbitos de trabajo actuales. El espíritu competitivo tiende a nublar la ética profesional cuando un usuario se entromete con los archivos de otro usuario. De hecho, el sabotaje puede ser una norma de conducta en algunos ambientes laborales donde la supervivencia se logra con una competencia extrema. La mayoría de los usuarios se comportará según un conjunto de reglas "sociales". Estas reglas los animan a respetar la privacidad y el trabajo de los demás. Semejante población de usuarios tiene una alianza de funcionamiento basada en la confianza, y la confianza es fácil subvertir. Una población de usuarios confiables es contaminada fácilmente por un usuario “malévolo”, que intente emplear mal los sistemas.

UNIDAD DIDÁCTICA 3. ANÁLISIS DE LOS EVENTOS REGISTRADOS POR EL IDS/IPS PARA DETERMINAR FALSOS POSITIVOS Y CARACTERIZARLOS EN LAS POLÍTICAS DE CORTE DEL IDS/IPS. Uno de los problemas principales con los sistemas de detección de intrusión es que suelen generar muchos falsos positivos. Un falso positivo se produce cuando el sistema genera una alerta basándose en lo que cree que es una actividad dañina o sospechosa pero en realidad es un tráfico normal en esa LAN. Generalmente, cuando establecemos un NIDS con sus configuraciones predeterminadas, va a buscar todo lo que sea ligeramente inusual. La mayoría de los sistemas de detección de intrusión de red tienen grandes bases de datos predeterminadas con miles de firmas de posibles actividades sospechosas. Los suministradores de IDS no tienen forma de saber la apariencia de nuestro tráfico de red, por lo que lo incluyen todo. Existen otras muchas fuentes de falsos positivos, dependiendo de la configuración de nuestra red y de su nivel de actividad. Un NIDS con una instalación predeterminada puede generar cientos de falsos positivos en un solo día, algo que puede conducir a un sensación de desesperación en el administrador del sistema. La reacción normal, es que las alertas de estos sistemas se ignoran a menudo debido a su falta de eficacia. Sin embargo, con poco esfuerzo y utilizando las técnicas descritas en este capítulo un IDS puede convertirse en una herramienta útil, en lugar de en la versión electrónica de la niña del exorcista. Las causas más comunes de los falsos positivos se describen en los siguientes apartados. Actividad del sistema de supervisión de red. Muchas empresas utilizan sistemas de supervisión de redes (NMS, Network Monitorig System) como HP OpenView o WhatsUp Gold para tener registros de la actividad de sus sistemas. Estos programas generan mucha actividad de sondeo y descubrimiento en nuestra red. Normalmente utilizan SNMP o algún protocolo similar para obtener el estado, pero pueden también utilizar pings y pruebas más intrusivas. De forma predeterminada, la mayoría de los sistemas de detección considerarán hostil esta actividad, o al menos, sospechosa. Un Nl\IIS en una red grande puede generar miles de alertas por hora, si se ha establecido en el IDS marcar este tipo de actividad. Se puede evitar haciendo que nuestro NIDS ignore la actividad desde y hacia la IP del NNIS. También podemos eliminar este tipo de alertas de la base de datos de nuestro NIDS, si no consideramos estas alertas importantes.

Escaneado de vulnerabilidad y escáneres de puertos de red. Si estamos realizando una prueba de vulnerabilidad de red o un escaneado de puertos utilizando programas como Nessus o Nmap, nuestro NIDS se volverá loco cada vez que se ejecuten dichos programas. Estos programas están diseñados para hacer exactamente lo que hacen los piratas informáticos. De hecho, probablemente exista una alerta para la mayoría de los complementos del programa Nessus. Una vez más, podemos deshabilitar el informe de la dirección IP de nuestro servidor Nessus o Nmap dentro del NIDS. Una mejor manera de controlar esta situación es apagar nuestro IDS durante los escaneados programados. Así, la IP del escáner seguirá protegida contra un ataque cuando no esté escaneando y nuestra base de datos de alertas no se cargará con datos de nuestra actividad de escaneado. Actividad de usuario. La mayoría de los sistemas de detección de intrusión de redes se configuran para marcar diversas actividades de usuario peligrosas, como compartir archivos punto a punto, mensajería instantánea, etc. Sin embargo, si permitimos este tipo de actividad, bien por política formal o simplemente sin imponer las políticas existentes, se mostrarán como alertas en nuestro registros. Este sería un buen momento para imponer o crear políticas contra su utilización ya que podemos demostrar cuánto ancho de banda y tiempo consumen, sin mencionar las implicaciones de seguridad. Aunque si pretendemos seguir permitiendo esta actividad, deberíamos comentar estas reglas para no rellenar los registros con alertas innecesarias. Comportamientos parecidos a los troyanos o gusanos. Normalmente, virus, gusanos y troyanos viven para la red. Intentan ejecutar diversas actividades por la red, incluyendo la infección de nuevas máquinas y el envío en masa de mensajes de correo electrónico. Estas actividades las puede detectar un NIDS, sin embargo, estas firmas también pueden ser activadas por una actividad normal de nuestra red. Podríamos desactivar las alertas que reconocen esta actividad, aunque exista un tráfico potencialmente dañino, para evitar vernos agobiados por los falsos positivos.

Cadenas largas de autenticación básica. Este tipo de alerta busca las cadenas de registro web largas, algunos ataques utilizan este método para conseguir un desbordamiento de memoria y obtener acceso al sistema. Sin embargo, hoy en día, muchas webs llenan este campo de información. Aunque, si desactivamos la regla para evitar falsos positivos, puede viajar código dañino por nuestra red y pasar inadvertido para el NIDS. Actividad de autenticación de base de datos. Algunos sistemas de detección de intrusión de red buscan actividades administrativas sobre bases de datos. La teoría es que el uso de bases de datos no debería de tener demasiada actividad administrativa en curso y ello podría ser señal de que alguien están intentando sabotearla. Sin embargo, muchas bases de datos tienen trabajos en proceso y mucha actividad administrativa incluso si no se están consultando. Esta actividad, aunque legítima, generará muchas de estas alertas. Si nuestras bases de datos están en constante desarrollo, probablemente deberemos desactivar dichas alertas, al menos hasta que se estabilicen y tengan un uso normal.

UNIDAD DIDÁCTICA 4. RELACIÓN DE LOS REGISTROS DE AUDITORÍA IDS/IPS NECESARIOS PARA MONITORIZAR Y SUPERVISAR SU CORRECTO FUNCIONAMIENTO Y LOS EVENTOS DE INTENTOS DE INTRUSIÓN. La Especialización en Auditoria de Sistemas proporciona los conocimientos necesarios para identificar los riesgos y diseñar controles en un ambiente computarizado, realizar la evaluación independiente del sistema de control y liderar el departamento de Auditoria de Sistemas en cualquier tipo de organización. Es innegable la importancia de la tecnología de información como factor crítico de éxito para las organizaciones. La toma de conciencia en las empresas de los riesgos inherentes a la actividad informática y de la necesidad de protección de altas inversiones que se dedican al diseño e implementación de Sistemas de Información, han permitido el desarrollo de la Auditoria de Sistemas en nuestro medio y ha creado una demanda constante de profesionales idóneos en este área. Es la auditoría de sistemas la encargada de liderar el montaje y desarrollo de la función de control en los ambientes computarizados, integrar la Auditoria de Sistemas con las demás „reas de la auditoria para contribuir a la modernización y eficiencia de esta función, realizar evaluaciones de riesgos en ambientes de sistemas y diseñar los controles apropiados para disminuir esos riesgos, además de participar en el desarrollo de los Sistemas de información, aportando el elemento de control y evaluar la administración de los recursos de información en cualquier organización. Un registro de auditoría registrará una entrada siempre que los usuarios realicen determinadas acciones que usted especifica. Por ejemplo, la modificación de un archivo o una directiva puede desencadenar una entrada de auditoría. La entrada de auditoría muestra la acción que se ha llevado a cabo, la cuenta de usuario asociada y la fecha y hora de la acción. Puede auditar tanto los intentos correctos como incorrectos en las acciones. El estado del sistema operativo y las aplicaciones de un equipo es dinámico. Por ejemplo, puede que sea necesario que los niveles de seguridad cambien de forma temporal para permitir la resolución inmediata de un problema relacionado con la administración o la red; muy a menudo, estos cambios se olvidan y nunca se deshacen. Esto significa que puede que un equipo ya no cumpla los requisitos de seguridad de la empresa. El análisis regular permite a un administrador hacer un seguimiento y garantizar un nivel adecuado de seguridad en cada equipo como parte de un programa de

administración de riesgos de la empresa. El análisis se centra en información altamente especificada sobre todos los aspectos del sistema relacionados con la seguridad. Esto permite que un administrador ajuste los niveles de seguridad y, lo más importante, detecte cualquier defecto de seguridad que pueda darse en el sistema con el tiempo. La auditoría de seguridad es extremadamente importante para cualquier sistema empresarial, ya que los registros de auditoría pueden que den la única indicación de que se ha producido una infracción de seguridad. Si se descubre la infracción de cualquier otra forma, la configuración de auditoría adecuada generará un registro de auditoría que contenga información importante sobre la infracción. A menudo, los registros de errores son mucho más informativos que los registros de aciertos, ya que los errores suelen indicar problemas. Por ejemplo, si un usuario inicia sesión correctamente en el sistema, puede considerarse como algo normal. Sin embargo, si un usuario intenta sin éxito iniciar sesión en un sistema varias veces, esto puede indicar que alguien está intentando obtener acceso al sistema utilizando el Id. de usuario de otra persona. El registro de seguridad registra sucesos de auditoría. El contenedor de registro de sucesos de directiva de grupo se utiliza para definir atributos relacionados con la aplicación, la seguridad y los registros de sucesos del sistema como, por ejemplo, el tamaño máximo del registro, los derechos de acceso para los registros, así como la configuración y los métodos de retención. Valores de auditoría. Las vulnerabilidades, contramedidas y posibles impactos de todos los valores de configuración de auditoría son idénticos, por lo que sólo se detallan una vez en los siguientes párrafos. Debajo de esos párrafos se incluyen breves explicaciones de cada valor. Las opciones para los valores de configuración de auditoría son:

Correcto.

Erróneo.

Sin auditoría. Vulnerabilidad. Si no se configura ninguna auditoría, será complicado o imposible determinar lo que sucedió durante un incidente de seguridad. No obstante, si se configura la

auditoría para que demasiadas actividades autorizadas generen sucesos, el registro de sucesos de seguridad se llenará de datos poco útiles. Configurar la auditoría para un gran número de objetos puede influir también en el rendimiento general del sistema. Contramedida. Todos los equipos de su organización deberían tener directivas de auditoría razonables habilitadas para que los usuarios legítimos puedan ser responsables de sus acciones y las actividades no autorizadas se puedan detectar y seguir. Impacto potencial. Si no se configura ninguna auditoría o si la auditoría tiene una configuración muy baja en los equipos de la organización, no habrá evidencias disponibles, o serán insuficientes, para el análisis de la red después de que se produzcan los incidentes de seguridad. Por otra parte, si se habilitan demasiadas auditorías el registro de seguridad se llenará de entradas carentes de sentido. Auditar sucesos de inicio de sesión de cuenta. El valor de configuración Auditar sucesos de inicio de sesión de cuenta determina si se debe auditar cada instancia de un usuario que inicie o cierre una sesión desde otro equipo, en la que el equipo que registra el suceso de auditoría se utiliza para validar la cuenta. Si define este valor de configuración de directiva, puede especificar si desea auditar los aciertos, los errores o no auditar el tipo de suceso. Las auditorías de aciertos generan una entrada de auditoría cuando un intento de inicio de sesión de cuenta tiene éxito, lo que ofrece información útil para establecer la responsabilidad y para la investigación tras el incidente, de forma que se pueda determinar quién consiguió iniciar sesión y en qué equipo. Las auditorías de errores generan una entrada de auditoría cuando en un intento de inicio de sesión de cuenta se produce un error, lo que resulta útil para la detección de intrusos, pero este valor de configuración también crea una posible condición de denegación de servicio (DoS), ya que un atacante puede generar millones de errores de inicio de sesión y llenar el registro de sucesos de seguridad. Si se habilita una auditoría de aciertos para los sucesos de inicio de sesión de cuenta en un controlador de dominio, se registrará una entrada para cada usuario que se valide en el controlador de dominio, aunque el usuario esté iniciando sesión en una estación de trabajo asociada al dominio.

Auditar la administración de cuentas. El valor de configuración Auditar la administración de cuentas determina si se deben auditar todos los sucesos de administración de cuentas de un equipo. Algunos ejemplos de sucesos de administración de cuentas incluyen:

Se crea, cambia o elimina una cuenta de usuario o grupo.

Cambia el nombre de una cuenta de usuario, o bien, se desactiva o se activa una.

Se establece o cambia una contraseña. Si define este valor de configuración de directiva, puede especificar si desea auditar los aciertos, los errores o no auditar el tipo de suceso. Las auditorías de aciertos generan una entrada de auditoría cuando cualquier suceso de administración de cuentas se lleva a cabo satisfactoriamente y deberían estar habilitadas en todos los equipos de la empresa. Es importante que las organizaciones puedan realizar un seguimiento de las personas que crearon, cambiaron o eliminaron una cuenta al responder a los incidentes de seguridad. Las auditorías de errores generan una entrada de auditoría cuando cualquier suceso de administración de cuentas produce un error. Auditar el acceso del servicio de directorio. El valor de configuración Auditar el acceso del servicio de directorio determina si se debe auditar el suceso de un usuario que tiene acceso a un objeto de Microsoft Active Directory que tiene su propia lista de control de acceso al sistema (SACL) especificada. Una SACL es una lista de usuarios y grupos cuyas acciones sobre un objeto se deben auditar en una red basada en Microsoft Windows 2000. Si define este valor de configuración de directiva, puede especificar si desea auditar los aciertos, los errores o no auditar el tipo de suceso. Las auditorías de aciertos generan una entrada de auditoría cuando un usuario obtiene acceso correctamente a un objeto de Active Directory que tiene una SACL especificada. Las auditorías de errores generan una entrada de auditoría cuando un usuario intenta obtener acceso sin éxito a un objeto de Active Directory que tiene una SACL especificada. La habilitación de la auditoría del acceso del servicio de directorio y la configuración de las SACL en los objetos de directorio puede generar un gran volumen de entradas en los registros de seguridad de los controladores de dominio, sólo debería habilitar esos valores si realmente desea utilizar la información creada.

Recuerde que puede establecer una SACL en un objeto de Active Directory utilizando la ficha Seguridad del cuadro de diálogo Propiedades de ese objeto. Esto es parecido a auditar el acceso a objetos, salvo que se aplica sólo a los objetos de Active Directory y no a los objetos del sistema de archivos y del registro. Auditar sucesos de inicio de sesión. El valor de configuración Auditar sucesos de inicio de sesión determina si se debe auditar cada instancia de un usuario que inicie, cierre una sesión o realice una conexión de red al equipo que registra el suceso de auditoría. Si está registrando sucesos de auditoría de inicio de sesión correctos de cuenta en un controlador de dominio, los intentos de inicio de sesión de la estación de trabajo no generan auditorías de inicio de sesión. Sólo los intentos de inicio de sesión de red e interactivos en el controlador de dominio propiamente dicho generan sucesos de inicio de sesión. En resumen, los sucesos de inicio de sesión de cuenta se generan donde se encuentra la cuenta; los sucesos de inicio de sesión se generan donde se produce el intento de inicio de sesión. Si define este valor de configuración de directiva, puede especificar si desea auditar los aciertos, los errores o no auditar el tipo de suceso. Las auditorías de aciertos generan una entrada de auditoría cuando un intento de inicio de sesión tiene éxito, esto ofrece información de utilidad para las cuentas y para la investigación tras el incidente de forma porque puede determinar quién consiguió registrarse en cada equipo. Las auditorías de errores generan una entrada de auditoría cuando un intento de inicio de sesión produce un error, lo que es útil para la detección de intrusos, pero este valor de configuración también crea una posible condición de denegación de servicio (DoS), ya que un atacante puede generar millones de errores de inicio de sesión y llenar el registro de sucesos de seguridad. Auditar el acceso a objetos. El valor de configuración Auditar el acceso a objetos determina si se debe auditar el suceso de un usuario que obtiene acceso a un objeto como, por ejemplo, un archivo, una carpeta, una clave de Registro, una impresora, etc., que tiene su propia lista de control de acceso al sistema especificada. Si define este valor de configuración de directiva, puede especificar si desea auditar los aciertos, los errores o no auditar el tipo de suceso. Las auditorías de aciertos generan una entrada de auditoría cuando un usuario obtiene acceso correctamente a un objeto que tiene una SACL especificada. Las auditorías de errores generan una entrada de auditoría cuando un usuario intenta obtener acceso sin éxito a un objeto que tiene una SACL especificada; hay que contar con que se produzcan algunos sucesos de error durante las operaciones de sistema normales. Por ejemplo, muchas aplicaciones, como Microsoft Word, siempre intentan abrir archivos con

privilegios tanto de lectura como de escritura, si no lo consiguen intentan abrirlos con privilegios de sólo lectura. Cuando esto ocurre, se registra un suceso de error si ha habilitado la auditoría de errores y la SACL adecuada en ese archivo. La habilitación de la auditoría de acceso de objetos y la configuración de las SACL en los objetos puede generar un gran volumen de entradas en los registros de seguridad de los sistemas de su empresa, por ello, sólo debería habilitar esos valores si realmente desea utilizar la información registrada. Nota: la habilitación de la capacidad de auditar un objeto, como un archivo, una carpeta, una impresora o una clave de Registro es un proceso que consta de dos pasos en Microsoft Windows Server 2003. Tras habilitar la directiva de auditoría de acceso a objetos, debe determinar los objetos cuyo acceso desee supervisar y, a continuación, modificar sus SACL como corresponda. Por ejemplo, si desea auditar cualquier intento por parte de los usuarios de abrir un archivo determinado, puede establecer el atributo de éxito o error directamente en el archivo que desee supervisar para ese suceso en particular mediante el Explorador de Windows o la directiva de grupo. Auditar el cambio de directivas. El valor de configuración Auditar el cambio de directivas determina si se debe auditar cada caso de cambio de las directivas de asignación de derechos de usuario, de auditoría o de confianza. Si define este valor de configuración de directiva, puede especificar si desea auditar los aciertos, los errores o no auditar el tipo de suceso. Las auditorías de aciertos generan una entrada de auditoría cuando un cambio en las directivas de asignación de derechos de usuario, de auditoría o de confianza se realiza correctamente, lo que ofrece información de utilidad para las cuentas y para la investigación tras el incidente de forma que pueda determinar quién consiguió modificar las directivas en el dominio o en los equipos individuales. Las auditorías de error generan una entrada de auditoría cuando se produce un error al realizar un cambio en las directivas de asignación de derechos de usuario, de auditoría o de confianza. Auditar el uso de privilegios. El valor de configuración Auditar el uso de privilegios determina si se debe auditar cada caso en el que un usuario ejecute un derecho de usuario. Si define este valor de configuración de directiva, puede especificar si desea auditar los aciertos, los errores o no auditar el tipo de suceso. Las auditorías de aciertos generan una entrada de auditoría cuando el ejercicio de un derecho de usuario tiene éxito. Las auditorías de errores generan una entrada de auditoría cuando el ejercicio de un derecho de usuario produce un error. El volumen de sucesos generados al habilitar

este valor de configuración es muy alto y muy difícil de clasificar. Sólo debe habilitar esta configuración si ha planeado cómo va a utilizar la información que se ha generado. De forma predeterminada, el uso de los siguientes derechos de usuario no genera sucesos de auditoría, aunque se haya especificado la auditoría de aciertos o la de errores para Auditar el uso de privilegios:

Omitir la comprobación de recorrido.

Depurar programas.

Crear un objeto Token.

Reemplazar un token de nivel de proceso.

Generar auditorías de seguridad.

Realizar copias de seguridad de archivos y directorios.

Restaurar archivos y directorios. Auditar el seguimiento de procesos. El valor de configuración Auditar el seguimiento de procesos determina si se debe auditar información de seguimiento detallada de sucesos como la activación de programas, la salida de procesos, la duplicación de identificadores y el acceso indirecto a objetos. Si define este valor de configuración de directiva, puede especificar si desea auditar los aciertos, los errores o no auditar el tipo de suceso. Las auditorías de aciertos generan una entrada de auditoría cuando el proceso que se está siguiendo tiene éxito. Las auditorías de errores generan una entrada de auditoría cuando el proceso que se está siguiendo produce un error. La habilitación del valor de configuración Auditar el seguimiento de procesos generará una cantidad considerable de sucesos, por lo que generalmente se establece en Sin auditoría. Sin embargo, estos valores pueden resultar muy útiles durante la respuesta a un incidente a partir del registro detallado de los procesos iniciados y la hora de inicio de los mismos. Auditar sucesos del sistema. El valor de configuración Auditar sucesos del sistema determina si se debe auditar el reinicio o cierre de un equipo realizado por un usuario o un suceso que afecte a

la seguridad del sistema o al registro de seguridad. Si define este valor de configuración de directiva, puede especificar si desea auditar los aciertos, los errores o no auditar el tipo de suceso. Las auditorías de aciertos generan una entrada de auditoría cuando un suceso del sistema se ejecuta correctamente. Las auditorías de errores generan una entrada de auditoría cuando se intenta ejecutar un suceso del sistema sin éxito. Como se registrarán muy pocos sucesos adicionales al habilitar las auditorías de aciertos y de errores para los sucesos del sistema y todos esos sucesos son muy significativos, se recomienda habilitar esta configuración en todos los equipos de la organización.

UNIDAD DIDÁCTICA 5. ESTABLECIMIENTO DE LOS NIVELES REQUERIDOS DE ACTUALIZACIÓN, MONITORIZACIÓN Y PRUEBAS DEL IDS/IPS. El modelo de detección de anomalías se basa en constantemente monitorear el sistema para así detectar cualquier cambio en los patrones de utilización o el comportamiento del mismo. Si algunos de los parámetros monitoreados sale de su regularidad, el sistema generará una alarma que avisará al administrador de la red sobre la detección de una anomalía. Este tipo de detección es bastante compleja, debido a que la cuantificación de los parámetros a observar no es sencilla y a raíz de esto, se pueden presentar los siguientes inconvenientes:

Pueden generarse falsas alarmas si el ambiente cambia repentinamente, por ejemplo, cambio en el horario de trabajo.

Un atacante puede ir cambiando lentamente su comportamiento para así engañar al sistema.

Según el tipo de monitoreo, hay SDI con detección orientada al host o detección orientada a la red. El modelo orientado al host se basa en el monitoreo y análisis de información, que refleja el estado del host donde éste reside. La mayoría de la información que este tipo de sistema recopila es obtenida a través del sistema operativo del host. Esto último causa complicaciones debido a que la información que se procesa no contiene registros del comportamiento, de bajo nivel, de la red. Los SDI que utilizan el modelo orientado a red, fundamentan su monitoreo en información recolectada de la red. Generalmente, ésta información es capturada mediante mecanismos de "sniffing". El "sniffing" consiste en habilitar la interfaz de red en modo promiscuo para que así capture todos los paquetes que reciba, incluso aquellos que no le han sido destinados. En base al mecanismo antes expuesto, se pueden definir patrones o firmas de ataques, según la estructura, información y ocurrencia de los paquetes. Cuando un sistema de detección de intrusos monitoriza el tráfico que atraviesa el enrutador y detecta un ataque, memoriza la dirección IP del pirata y enruta todo el tráfico hacia un honeypot situado en una DMZ aparte. Uno de los sistemas de IDS particularmente extendido es Snort, pues se proporciona en forma de software abierto, es decir, es gratuito y fácil de obtener, descargándolo de su página en Internet. Además, dispone de una base de firmas muy grande, realizada por la comunidad de usuarios. Es garantía de obtener rápidamente actualizaciones de la base cuando se señala una nueva amenaza.

Aunque la base de firmas se extensa, requiere un trabajo constante por parte del administrador, que debe descargar dichas actualizaciones manualmente pues no hay ningún proceso automático para ello. El software también incluye una actualización automática diaria de la aplicación y de la base de formas.

MÓDULO 3. CONTROL DE CÓDIGO MALICIOSO. UNIDAD DIDÁCTICA 1. SISTEMAS DE DETECCIÓN Y CONTENCIÓN DE CÓDIGO MALICIOSO. Códigos maliciosos. En seguridad informática, código malicioso (“malicious code”, “vandals”) es un término que hace referencia a cualquier conjunto de códigos, especialmente sentencias de programación, que tiene un fin malicioso. Esta definición incluye tanto programas malignos compilados, como macros y códigos que se ejecutan directamente, como los que suelen emplearse en las páginas web (“scripts”). Los códigos maliciosos pueden tener múltiples objetivos como los mencionados a continuación:

Extenderse por la computadora, otras computadoras en una red o por internet.

Robar información y claves.

Eliminar archivos e incluso formatear el disco duro.

Mostrar publicidad invasiva. Mínimos cambios en un código malicioso, pueden hacer que ya no sea reconocido como malicioso por un programa antivirus; es por esta razón que existen tantas variantes de los virus, los gusanos y otros “malwares” (códigos maliciosos). Además, los antivirus todavía no tienen la suficiente "inteligencia" como para detectar códigos maliciosos nuevos. Tipos de códigos maliciosos. Algunos de los códigos maliciosos más comunes son los troyanos y los gusanos que serán explicados a continuación: Troyanos. Un troyano era en sus comienzos, un programa que camuflado dentro de otro (de ahí el nombre, asociado al caballo que los griegos utilizaron para ganar su guerra contra Troya) para conseguir que un usuario de un ordenador lo ejecutara pensando que en realidad estaba ejecutando un programa lícito. Estos troyanos, tenían multitud de funciones, algunas destructivas y otras no, y se diferenciaban de los virus comunes en su incapacidad para autoreproducirse, es

decir, que no podían crear copias de si mismos para infectar otros ordenadores y dependía de la acción del usuario del ordenador para realizar su fin. Hablamos en pasado porque, aunque la definición de troyanos sigue siendo válida, los últimos años han visto surgir un gran número de troyanos con unas características especiales, que se han generalizado ampliando su definición al término troyano. Estos nuevos troyanos, responden más concretamente a la definición de “Backdoor” o Puerta trasera, es decir, que abren un canal de comunicación en el ordenador infectado que permite que otro ordenador se conecte a él para realizar acciones sin que el usuario legítimo de este ordenador sea consciente de ello. Estos troyanos pueden realizar tareas "simples", como robar claves, buscando un cierto formato en la información de los usuarios (por ejemplo, las tarjetas VISA se identifican con 4 grupos de 4 números y un grupo más, la fecha de caducidad, que consta de 2 grupos de 2 números separados por una barra) o llegan incluso a permitir al "atacante" que tome control del ordenador, abriendo y cerrando programas, creando y borrando ficheros, etc. Con la aparición de la banda ancha (cable o ADSL) y la posibilidad de mantenerse conectado a Internet durante 24 horas al día, los Troyanos se han puesto de moda, ya que permiten a un atacante, tomar control de un ordenador víctima a través de Internet y manejarlo a su antojo sin ningún tipo de problema. Incluso se pueden crear redes de ordenadores controlados por un solo atacante que puede utilizarlo para actividades ilícitas (por ejemplo atacar un sitio Web y "tumbar" la página). Gusanos. Otro tipo de código malicioso son los gusanos. Primos hermanos de los virus, su principal misión es reproducirse y extenderse al mayor número de ordenadores posibles. Internet y el correo electrónico han supuesto el verdadero auge de este tipo de código malicioso, que pueden infectar miles de ordenadores en cuestión de horas. Posiblemente menos peligrosos para los usuarios domésticos que otros, su mayor poder es en el ataque a grandes sistemas de empresas o los ordenadores que sostienen Internet. Su poder de multiplicación es capaz de colapsar grandes ordenadores rápidamente y "tumbar" los servicios que den (servidores de correo electrónico, de páginas web...).

Su mecanismo de distribución suele ser en la mayoría de los casos muy simple. Camuflados en un mensaje aparentemente inocente, llegan a nuestro correo electrónico. Una vez ejecutado leen nuestra lista de contactos (libreta de direcciones o “Address Book”) y se renvían de forma automática a todas las direcciones que contengan. Nuestros contactos recibirán un correo, aparentemente enviado por nosotros, y por tanto lo abrirán sin sospechar nada y vuelta a empezar. Este tipo de código malicioso utiliza en muchas ocasiones lo que denominamos Ingeniería social, es decir, intenta aparecer atractivo para nosotros, a fin que no sospechemos y lo ejecutemos rápidamente. Promesas de fotografías, juegos, listados de páginas con contenido erótico... son algunos de los trucos que han usado los creadores de estos engendros para llamar nuestra atención. Los defensores: Antivirus y “Firewalls” Personales. Estas y otras razones han hermanado a los antivirus y los firewalls personales. Un Antivirus es un programa que intenta proteger un ordenador o red de ordenadores de todo tipo de código malicioso que pudiera llegar a este equipo. Existen antivirus especializados en diferentes entornos, correo, ficheros... Básicamente un antivirus funciona de una forma muy simple, revisa todo los ficheros (o correo en su caso) que llega al equipo y bloquea todo aquello que cree que puede contener un código malicioso. Para que el antivirus identifique un código malicioso básicamente existen 2 métodos complementarios. El más habitual es comparar trozos de ese código con una base de datos de firmas que contiene el antivirus y que es actualizada constantemente. Si coinciden, es que es un código malicioso y no se deja pasar. La otra técnica consiste en ver cual es el comportamiento de ese fichero, buscando acciones extrañas (como formatear el disco duro, infectar ficheros...). Este último método sólo puede dar cierta información de que hay algo raro en el fichero, pero no qué virus es. Los “Firewalls” personales son un complemento perfecto de los antivirus clásicos, por eso los mejores fabricantes de antivirus los incluyen dentro de sus últimas versiones.

Para entender como funcionan los “firewalls” personales, queremos resumir primero cómo funcionan las comunicaciones entre ordenadores (de forma parecida al servicio de correos). Cuando alguien quiere enviar una carta, Correos se encarga de dar el servicio de envío a otro lugar. Es decir, es el "servidor" (el que da el servicio). Cuando se envía una carta ésta debe ir en un sobre y con sello, este sobre sería el que posibilita la comunicación por parte del cliente. El sobre es depositado en el buzón o la oficina de correos. Siguiendo esta analogía, el ordenador que pide el servicio (cliente), se comunica con el servidor (correos), que es el ordenador que da el servicio. Para establecer la comunicación utiliza un puerto (el sobre y el sello) y se conecta a otro puerto del servidor (el buzón u oficina de correos). Lo que hace un “firewall” personal es bloquear esa comunicación, cuando se sale de los cauces normales establecidos por el usuario. Es decir, si un ordenador se conecta a una página web con su navegador, esto es una comunicación normal y permitida, por lo que el “firewall” lo deja pasar (no bloquea el puerto de esa comunicación), sin embargo si es un troyano el que intenta comunicarse con el ordenador atacante, a fin de tomar control de ese ordenador, intenta comunicarse por un puerto no permitido y el “firewall” lo bloquea. Sería como quitar el buzón o cerrar la oficina de correos.

UNIDAD DIDÁCTICA 2. RELACIÓN DE LOS DISTINTOS TIPOS DE HERRAMIENTAS DE CONTROL DE CÓDIGO MALICIOSO EN FUNCIÓN DE LA TOPOLOGÍA E LA INSTALACIÓN Y LAS VÍAS DE INFECCIÓN A CONTROLAR. En la actualidad, la propagación de virus, gusanos y ataques automáticos en Internet ha crecido enormemente. Hace unos años, en 2001, “Code Red” y “Nimda” infectaron cientos de miles de equipos causando pérdidas por millones de dólares. Luego de una relativa calma apareció “SQL Slammer” en enero de 2003, y se esparció rápidamente a través de Internet. Por su rápido mecanismo de escaneo, logró infectar a un 90% de los host vulnerables en los primeros 10 minutos, además la enorme cantidad de paquetes de escaneo generados por el slammer ocasionó un ataque de denegación de servicio a nivel global en Internet, muchas redes en Asia, Europa y América estuvieron fuera de servicio durante horas. Algunas de ellas con gran importancia son las siguientes:

Arania: es una herramienta para colectar código malicioso en ataques de inyección de código a servidores web en producción. Se explica la importancia de dicha herramienta al ser no intrusiva, a diferencia de los honeypots.

El diseño de arania es simple y concreto, se cumplen varios objetivos:

1. Monitorea de forma automáticas los registros del servidor web. 2. Es un modelo no- intrusivo, no afecta el funcionamiento del servidor

web. 3. Obtiene el código malicioso que se trato de incluir. 4. Lo almacena marcándolo de acuerdo a su contenido. 5. Mantiene un registro detallado.

Arania es una herramienta que nació de la necesidad de contar con mayor información sobre las herramientas utilizadas para atacar aplicaciones web, aunque originalmente se desarrolló para el CMS de Mambo, ahora puede utilizarse de forma general para obtener el código malicioso en ataques de inyección de código y de inclusión de código remoto en una gran variedad de aplicaciones web.

FileInsight: esta útil herramienta de la compañía McAfee, está diseñada para analizar páginas web y verificar si éstas cuentan o no con código malicioso. Esta aplicación es realmente útil, ya que nos permite verificar si una página web está limpia de malware; lo cual no sólo nos ayuda a mantener nuestro equipo personal limpio de código malicioso, sino que también nos permite realizar auditorías para verificar, si los usuarios de

nuestra red están accediendo a sitios sospechosos de tener código malicioso.

Virus Total: esta aplicación online de Hispasec Sistemas, es completamente gratuita y nos permite analizar archivos sospechosos de contener virus, malware, e incluso analizar correos electrónicos; para de esta manera, poder abrir con tranquilidad estos archivos en nuestros PC´s.

Para utilizar esta herramienta, sólo debemos enviar el archivo sospechoso a Virus Total, para que éste realice un análisis completo del archivo y despeje las dudas, sobre si está infectado o no con algún malware o virus. Esta aplicación trabaja con los principales motores de antivirus y antimalware, entre los cuales podemos destacar: Avast!, Avira, Quick Heal, Clamwin, NOD 32, AVG, Antivir, Ikarus, Panda Platinum, BitDefender, Norton Antivirus, entre otros.

UNIDAD DIDÁCTICA 3. CRITERIOS DE SEGURIDAD PARA LA CONFIGURACIÓN DE LAS HERRAMIENTAS DE PROTECCIÓN FRENTE A CÓDIGO MALICIOSO. Los errores generados en el software durante la aplicación de una instalación, pueden ser aprovechados por software malicioso para producir daños en el sistema, este hecho amenaza la integridad y la confidencialidad de los datos y debe ser gestionado adecuadamente. Los virus informáticos son aplicaciones o trozos de código que aprovechan estos errores. En la gran mayoría de los casos se debe establecer una política de protección del sistema de información que incluya la instalación en todos los equipos de un software antivirus. En el caso, por ejemplo del ámbito empresarial, se deben adoptar medidas de seguridad complementarias a la instalación de un antivirus, como son establecer una planificación de actualizaciones del mismo, formar y concienciar al personal para que eviten la ejecución de archivos o lectura de mensajes no reconocidos, recomendando la eliminación de los mismos. También se debe contemplar en las medidas la prohibición de instalación de software sin licencia, ya que dicho software podría encubrir al software malicioso (virus, troyanos, etc.), así como el uso de software no autorizado específicamente por la organización. La implantación de normas de protección contra código malicioso está reflejada en la norma ISO 17799 en el siguiente punto: “Se deberán poner en marcha medidas para la detección, prevención y recuperación del sistema frente a código malicioso, así como procedimientos de concienciación de los usuarios”. Un buen ejemplo puede ser el de una empresa que no ha definido ninguna política de seguridad con respecto al malware y códigos maliciosos. Los equipos no tienen instalada ninguna solución antivirus (porque no se conectan a Internet), en los ordenadores se instala un software no legal de una aplicación que se descargó en su casa uno de los miembros de la empresa de fuentes no fiables. Los usuarios utilizan CD’s y disquetes de fuera de las instalaciones en los equipos del sistema de información de la empresa. Amenazas posibles:

Posible infección desde soportes extraíbles.

Posible infección por instalación de software no fiable.

Violación de la ley de propiedad intelectual.

La empresa decide instalar en todos los equipos un antivirus y mantenerlo actualizado, y establece normas para que cualquier soporte que se utilice (que no pertenezca a la empresa) primero se escanee con dicho antivirus. También establece normas para que solo el software legal y autorizado por la empresa sea instalado en los equipos del sistema de información. Se debe definir un procedimiento de instalación y actualización de antivirus en la organización, desarrollando actuaciones de formación y concienciación complementarias a usuarios, para evitar la entrada de código malicioso en el sistema. Es importante que al momento de formular las políticas de seguridad informática, se consideren por lo menos los siguientes aspectos:

Efectuar un análisis de riesgos informáticos, para valorar los activos y así adecuar las políticas a la realidad de la organización.

Reunirse con los departamentos dueños de los recursos, ya que ellos poseen la experiencia y son la principal fuente para establecer el alcance y definir las violaciones a las políticas.

Comunicar a todo el personal involucrado sobre el desarrollo de las políticas, incluyendo los beneficios y riesgos relacionados con los recursos y bienes, y sus elementos de seguridad.

Identificar quién tiene la autoridad para tomar decisiones en cada departamento, pues son ellos los interesados en salvaguardar los activos críticos de su área.

Monitorear periódicamente los procedimientos y operaciones de la organización, de forma tal, que ante cambios las políticas puedan actualizarse oportunamente.

Detallar explícita y concretamente el alcance de las políticas con el propósito de evitar situaciones de tensión al momento de establecer los mecanismos de seguridad que respondan a las políticas trazadas.

Siguiendo algunos sencillos consejos se puede aumentar considerablemente la seguridad de los sistemas informáticos ante el código malicioso, algunos son:

Protección a través del número de cliente y la del generador de claves dinámicas.

Tener el sistema operativo y el navegador web actualizados.

Tener instalado un antivirus y un firewall y configurarlos para que se actualicen automáticamente de forma regular ya que cada día aparecen nuevas amenazas.

Utilizar una cuenta de usuario con privilegios limitados, la cuenta de administrador solo debe utilizarse cuando sea necesario cambiar la configuración o instalar un nuevo software.

Tener precaución al ejecutar software procedente de Internet o de medios extraíbles como CD o memorias USB. Es importante asegurarse de que proceden de algún sitio de confianza.

Evitar descargar software de redes P2P, ya que realmente no se sabe su contenido ni su procedencia.

Desactivar la interpretación de Visual Basic Script y permitir JavaScript, ActiveX y cookies sólo en páginas web de confianza.

Utilizar contraseñas de alta seguridad para evitar ataques de diccionario. Es muy recomendable hacer copias de respaldo regularmente de los documentos importantes a medios extraíbles como CD o DVD para poderlos recuperar en caso de infección por parte de algún malware.

UNIDAD DIDÁCTICA 4. DETERMINACIÓN DE LOS REQUERIMIENTOS Y TÉCNICAS DE ACTUALIZACIÓN DE LAS HERRAMIENTAS DE PROTECCIÓN FRENTE A CÓDIGO MALICIOSO. Herramientas de análisis IDS. Los sistemas de detección normalmente ofrecen a los administradores varios métodos de notificación de una alerta.

En su nivel más básico, las alertas pueden simplemente enviarse a un archivo de registro para una revisión posterior, algo que no es muy recomendable ya que requiere que el administrador revise los registros. Si no se supervisan diariamente, pueden pasar días o semanas antes de descubrir los intentos de intrusión.

La otra alternativa es enviar un mensaje de correo electrónico o una página, a la persona apropiada siempre que se genere una alerta. Sin embargo, incluso en un sistema bien ajustado, puede ser molesto recibir correos varias veces al día. Así mismo, las alertas de correo electrónico no estarían en un formato en el que se puedan comparar con alertas pasadas o analizadas de otra forma.

La mejor solución para controlar las alertas IDS es insertarlas en una base de datos, para permitir un análisis más profundo.

IDS Snort (NIDS). Es una herramienta desarrollada por Martin Roesch, aunque ahora ya cuenta con 30 desarrolladores más en su equipo principal, sin contar con los que escriben reglas y otras partes del software. Existen muchos recursos disponibles para Snort y todos ellos son recursos gratuitos disponibles en Internet. Snort es principalmente un IDS basado en firmas, aunque con la adición del módulo Spade, puede realizar una detección de actividad de anomalías. Existen también otros módulos de complemento como Inline Snort que permite a Snort realizar acciones predeterminadas ante determinadas alertas. Características básicas. Libre distribución. Snort es de libre distribución y portable a casi cualquier sistema operativo Unix/Linux. También existen versiones disponibles para Windows y otros sistemas operativos.

Ligero. Debido a que el código se ejecuta de una forma eficiente, no requiere mucho hardware, lo que permite poder analizar tráfico en una red de 100 Mbps a una velocidad cercana al cable, algo bastante increíble si pensamos lo que hace con cada paquete. Snort personaliza reglas. Snort ofrece una forma fácil para ampliar y personalizar el programa escribiendo nuestras propias reglas o firmas. Existe mucha documentación que puede ayudarnos a aprender a hacer reglas, sin mencionar la cantidad de foros sobre el tema. Modo de detección de intrusión (IDS). Este modo lo utiliza Snort para registrar paquetes sospechosos o que merecen una consideración especial. Sólo necesitamos un modificador adicional a la declaración anterior para que Snort entre en este modo. El modificador: -c configfile, le indica a Snort que utilice un archivo de configuración para dirigir los paquetes que registra. Este archivo determina la configuración de Snort, se incluye un archivo predeterminado, pero debemos realizar cambios antes de ejecutarlo, para que refleje nuestro perfil de red. Por lo tanto, si escribimos: #snort -de -l /var/log/snort -h 192.168.0.0/24 -c /etc/snort/snort.conf Ejecutaremos Snort en modo IDS utilizando el archivo de configuración snort.conf predeterminado. Hay que tener en cuenta que no hemos utilizado el modificador -v para ejecutar Snort en modo IDS. Cuando intentamos comparar todos los paquetes con las firmas, obligar a Snort a escribir también las alertas en la pantalla puede causar que algunos paquetes se omitan, especialmente en redes con mucho tráfico. También podemos omitir el modificador -e si no necesitamos registrar las capas de enlace de datos. Si omitimos el modificador -l, Snort de forma predeterminada utilizará /var/log/snort como su directorio de registro. También podemos utilizar el modificador -b si deseamos registrar un archivo binario para un análisis posterior con un programa independiente. El comando para ejecutar Snort en el modo IDS es: #snort -h 192.168.0.0/24 -c /etc/snort/snort.conf

Técnicas para asegurar el sistema.

Codificar la información. Criptología, Criptografía y Criptociencia, contraseñas difíciles de averiguar a partir de datos personales del individuo.

Vigilancia de red. Zona desmilitarizada.

Tecnologías repelentes o protectoras: cortafuegos, sistema de detección de intrusos - antispyware, antivirus, llaves para protección de software, etc. Mantener los sistemas de información con las actualizaciones que más impacten en la seguridad.

Sistema de Respaldo Remoto. Servicio de backup remoto.

UNIDAD DIDÁCTICA 5. RELACIÓN DE LOS REGISTROS DE AUDITORÍA DE

LAS HERRAMIENTAS DE PROTECCIÓN FRENTE A CÓDIGO MALICIOSO

NECESARIOS PARA MONITORIZAR Y SUPERSIVAR SU CORRECTO

FUNCIONAMIENTO Y LOS EVENTOS DE SEGURIDAD.

La auditoría informática es un proceso llevado a cabo por profesionales especialmente capacitados para el efecto, y que consiste en recoger, agrupar y evaluar evidencias para determinar si un sistema de información salvaguarda el activo empresarial, mantiene la integridad de los datos, lleva a cabo eficazmente los fines de la organización, utiliza eficientemente los recursos, y cumple con las leyes y regulaciones establecidas. Permiten detectar de forma sistemática el uso de los recursos y los flujos de información dentro de una organización y determinar qué información es crítica para el cumplimiento de su misión y objetivos, identificando necesidades, duplicidades, costes, valor y barreras, que obstaculizan flujos de información eficientes. Auditar consiste principalmente en estudiar los mecanismos de control que están implantados en una empresa u organización, determinando si los mismos son adecuados y cumplen unos determinados objetivos o estrategias, estableciendo los cambios que se deberían realizar para la consecución de los mismos. Los mecanismos de control pueden ser directivos, preventivos, de detección, correctivos o de recuperación ante una contingencia. Para comenzar a plantear la definición y los conceptos de la Auditoria de Sistemas e Informática, debemos posicionarnos en ¿Que es AUDITORIA? El término de Auditoría muchas veces se ha empleado incorrectamente y con frecuencia sólo se le considera como una evaluación cuyo único fin es detectar errores y señalar fallos. Pero la auditoría y el control van más allá de detectar fallas. La palabra auditoría proviene del latín auditorius, y de ella se deriva la palabra auditor, que se refiere a todo aquel que tiene la virtud de oír. Concepto de Auditoría. Es un examen crítico que se realiza con el fin de evaluar la eficacia y eficiencia de una sección, un organismo, una entidad, etc. Función del Control. Una definición que es correcta y a la cual representa el valor de la Función del Control es la de ayudar a los Funcionarios que tienen responsabilidad Administrativa, Técnica y/u Operacional a que no incurran en falta. Y es por ello que aquí el Control es Creativo, Inteligente, y Constructivo de asesoramiento

oportuno a todas las Direcciones o Gerencias a fin de que la Toma de Decisiones sea acertada, segura y se logren los objetivos, con la máxima eficiencia. El Control de Sistemas e Informática. Consiste en examinar los recursos, las operaciones, los beneficios y los gastos de las producciones (servicios y/o productos de los Sistemas Informáticos), de los Organismos sujetos a control, con al finalidad de evaluar la eficacia y eficiencia Administrativa Técnica y/u Operacional de los Organismos, en concordancia con los principios, normas, técnicas y procedimientos normalmente aceptados. Asimismo de los Sistemas (Planes, Programas y Presupuestos, Diseño, Software, Hardware, Seguridad, Respaldos y otros) adoptados por la Organización para su dinámica de Gestión en salvaguarda de los Recursos del Estado. Existe otra definición sobre el "control técnico" en materia de Sistemas e Informática, y esta se orienta a la revisión del Diseño de los Planes, Diseños de los Sistemas, la demostración de su eficacia, la Supervisión compulsa de rendimientos, Pruebas de Productividad de la Gestión/Demanda llamada "Pruebas intermedias", el análisis de resultados, niveles y medios de seguridad, respaldo, y el almacenamiento. Así mismo medición de la vida útil del Sistema Informático adoptado por la Organización bajo control. Objetivos de la Auditoría y Control de Sistemas e Informática. Los principales objetivos que constituyen a la auditoría Informática son:

El control de la función informática (Sistema de Información: SI y la Tecnología de la Información: TI).

El análisis de la eficiencia de los SI y la TI.

La verificación del cumplimiento de la Normativa General de la Organización.

La verificación de los Planes, Programas y Presupuestos de los Sistemas Informáticos.

La revisión de la eficaz gestión de los recursos materiales y humanos informáticos.

La revisión y verificación de Controles Técnicos Generales y Específicos de Operatividad.

La revisión y verificación de las Seguridades:

1. De Cumplimiento de normas y estándares.

2. De Sistema Operativo.

3. De Seguridad de Software.

4. De Seguridad de Comunicaciones.

5. De Seguridad de Base de Datos.

6. De Seguridad de Proceso.

7. De Seguridad de Aplicaciones.

8. De Seguridad Física.

9. De Suministros y Reposiciones.

10. De Contingencias.

11. El análisis del control de resultados.

12. El análisis de verificación y de exposición de debilidades y disfunciones. El auditor informático. Es el profesional que ha de cuidar y velar por la correcta utilización de los diversos recursos de la organización y debe comprobar que se esté llevando a cabo un eficiente y eficaz Sistema de Información y la Tecnología de la Información. Pues estos dos puntos en la actualidad soportan la Auditoría y Control de los Sistemas e Informática en la Gestión moderna. Cuando se aplica el CIPOD en la Auditoría y Control de Sistemas e Informática, nos encontramos que en ella no da "Indicios, anomalías y síntomas" que nos permite percibir que la Organización bajo control esta con problemas de resultados como de eficacia y eficiencia en los Sistemas Informáticos y en la Tecnología de la Información.

Herramientas y Técnicas para la Auditoría Informática:

Cuestionarios.

Entrevistas.

Formularios Checklist.

Formularios Virtuales.

Pruebas de Consistencias.

Inventarios y Valorizaciones.

Historias de cambios y mejoras.

Reporte de Bases de Datos y Archivos.

Reportes de Estándares.

Compatibilidades e Uniformidades.

Software de Interrogación.

Certificados, Garantías, otros del Software.

Fotografías o Tomas de Valor (Imágenes).

Diseño de Flujos y de la red de Información.

Planos de Distribución e Instalación (Para Estudio y Revisión).

Listado de Proveedores.

Otros. Para finalizar, exponemos los pasos más recomendables para la implantación del área de auditoría en informática:

Presentar la propuesta al Comité de Administración para la implantación del área de auditoría en informática.

Revisión de la propuesta para la implantación del área.

Aprobación de la propuesta.

Modificaciones a la estructura orgánica y normatividad pertinente.

Solicitud de recursos para infraestructura, personal, software y/o capacitación.

Remodelación de áreas.

Contratación y/o capacitación de personal.

Adquisición de equipo de hardware.

Adquisición de software especializado.

Inclusión de la(s) auditoría(s) en el PACA.

Aplicación de la metodología para las revisiones al área de sistemas.

UNIDAD DIDÁCTICA 6. ESTABLECIMIENTO DE LA MONITORIZACIÓN Y

PRUEBAS DE LAS HERRAMIENTAS DE PROTECCIÓN FRENTE A CÓDIGO

MALICIOSO.

Para comenzar con el desarrollo de la unidad, vamos a tomar una perspectiva más amplia y comenzar por visualizar los distintos tipos de ataques, así como los modos de monitorización que ciertos agentes de código malicioso pueden ejecutar y perjudicar nuestro sistema informático. Ataques. La finalidad de los IDS es detectar las intrusiones o ataques que sufre al sistema que protegen. Como hemos mencionado anteriormente, cada día surgen nuevos ataques y vulnerabilidades que complican su detección.

Según la naturaleza de los ataques estos pueden clasificarse en:

- Pasivos. Se trata de intrusiones en un sistema sin consecuencias para este. Por lo general se hacen para demostrar las vulnerabilidades de un sistema o como retos que se ponen a sí mismo los hackers más experimentados al entrar en sistemas muy protegidos.

- Activos. En esta ocasión la intrusión en el sistema se usa para dañarlo

modificando o eliminando archivos. Son los ataques más perjudiciales y con consecuencias más graves.

Según el origen del atacante los ataques pueden ser:

- Internos. El ataque proviene de la propia red. Puede ser realizado por usuarios de la red o por atacantes que suplantan alguna identidad. Son muy peligrosos debido a los privilegios que se tiene sobre el sistema (especialmente si trata de la identidad de un administrador).

- Externos. Los ataques provienen del exterior del sistema, en general se

hacen a través de internet. Son los ataques más conocidos y lo que se conoce popularmente como hacking o pirateo informático.

Monitorización. Estos ataques se ejecutan para observar a la víctima y su sistema. De esta manera, será posible obtener información muy valiosa, con el objetivo de enumerar sus debilidades y encontrar posibles formas de acceso al sistema monitorizado.

Decoy. Son programas que imitan la interfaz de otras aplicaciones usadas normalmente por los usuarios. Estos programas requieren la identificación del usuario mediante su login y contraseña. El programa guarda la información en un fichero y ejecuta la aplicación a la que imitan para que el usuario no detecte nada anormal. El atacante podrá así suplantar la identidad del usuario del sistema. Otros ataques de este tipo son los Keyloggers que guardan todas las teclas pulsadas por una persona en una sesión. Después, el atacante puede investigar el fichero generado para obtener contraseñas y nombres de usuarios. Escaneo. El escaneo es el método por el que se descubren canales de comunicación susceptibles de ser utilizados por el intruso. Consiste en el envío de paquetes de diferentes protocolos a los puertos de la máquina víctima para averiguar qué servicios (puertos) están abiertos según la recepción o extravío de paquetes de respuesta. Escaneo fragmentado. Este procedimiento consiste en fragmentar los paquetes de sondeo dirigidos a la máquina víctima. Con esto conseguimos provocar menos ruido en las herramientas de protección del sistema objetivo. Sniffering. Consiste en, una vez dentro de una red de ordenadores, ejecutar en alguna de las máquinas del sistema un programa espía, llamado sniffer. Este programa registra en un fichero todo el tráfico que pasa por la red. En este fichero pueden descubrirse todo tipo de datos como contraseñas, números de cuenta bancaria, etc. Por lo general, estos datos estarán encriptados por lo que su lectura no será sencilla. Principales pruebas y herramientas para efectuar una auditoria informática. En la realización de una auditoría informática el auditor puede realizar las siguientes pruebas: Pruebas sustantivas. Verifican el grado de confiabilidad del organismo. Se suelen obtener mediante observación, cálculos, muestreos, entrevistas, técnicas de

examen analítico, revisiones y conciliaciones. Verifican asimismo la exactitud, integridad y validez de la información. Pruebas de cumplimiento. Verifican el grado de cumplimiento de lo revelado mediante el análisis de la muestra. Proporciona evidencias de que los controles clave existen y que son aplicables efectiva y uniformemente. Por otra parte, las principales herramientas de las que dispone un auditor informático son:

Observación.

Realización de cuestionarios.

Entrevistas a auditados y no auditados.

Muestreo estadístico.

Flujogramas.

Listas de chequeo.

Mapas conceptuales.

Etc. El siguiente es un ejemplo de cómo funciona un flujograma.

UNIDAD DIDÁCTICA 7. ANÁLISIS DE LOS PROGRAMAS MALICIOSOS MEDIANTE DESENSAMBLADORES Y ENTORNOS DE EJECUCIÓN CONTROLADA. SecuBT. Un ejemplo de entorno de ejecución controlada. La plataforma secuBT y, en general los entornos de ejecución controlados, están orientados a la traducción de binarios para poder ejecutar código malicioso en un entorno seguro. La plataforma utiliza traducción dinámica de código, en la que se van traduciendo los bloques de instrucciones a medida que es necesario ejecutarlas y las mete en una cache, de acuerdo al siguiente diagrama, de modo que los bloques de código sólo se traducen cuando van a ser ejecutados. Respecto a la protección, se obtiene por dos circunstancias:

Por un lado, todo el código traducido tiene privilegios menores que los de la librería del sistema.

Por otro lado, todas las llamadas al sistema son chequeadas y traducidas dentro del entorno virtualizado.

Para que funcione a una velocidad razonable, el programa introduce optimizaciones en la eficiencia de traducción y en la de ejecución:

Respecto a la eficiencia de traducción, tras evaluar la posibilidad de tener una traducción a código intermedio que luego se optimiza, se decidieron por la estrategia más sencilla de tener una tabla de traducción para el código, que es simple y rápida.

Respecto a la eficiencia en la ejecución, el programa introduce optimizaciones en múltiples sentidos, como ejemplo se han contado algunas de las posibles implementaciones de las llamadas indirectas (ya que todas las instrucciones que afectan al flujo de control se tratan de manera especial), para intentar disminuir su peso (la traducción estándar requiere sustituir esa única llamada por treinta instrucciones):

- La implementación estática se traducen por una llamada con cache, de

modo que se compara el destino con el anterior de esta misma llamada y si coincide no se ejecutan el resto de las comprobaciones, y su eficiencia depende de la tasa de aciertos.

- En las llamadas dinámicas, se utiliza una tabla de hash para las direcciones "permitidas", y si se encuentra en esa tabla, tampoco se hacen todas las comprobaciones

El hecho de utilizar la traducción dinámica se traduce en la posibilidad de endurecer la seguridad con la que se ejecuta el programa:

Forzar la protección frente a ejecución en zonas de datos, como el heap o stack. Aunque los procesadores de Intel tienen esta funcionalidad, no todos los SO la tienen habilitada.

Comprobar todas las cabeceras ELF.

Proteger todas las estructuras de datos internas, utilizando mprotect para proteger todas las escrituras a memoria a las estructuras del entorno, salvo cuando se está ejecutando código de la propia máquina virtual.

Interceptar todas las llamadas al sistema, tanto para permitirla, denegarla, devolver un valor artificial o traducirla a una llamada a código de usuario que haga lo que queramos. Por ejemplo, para hacer creer al código que tiene privilegios de root (de lo cual se incluía una demo).

Todas estas medidas ofrecen protección frente a los tres tipos más clásicos de problemas: la ejecución de código en el stack / heap que ha llegado ahí mediante un heap overflow, el retorno a libc y o la rescritura de la dirección de retorno, de los cuales se ha incluido una demo en la charla. Desensambladores. Es un programa de ordenador que traduce el lenguaje de máquina a lenguaje ensamblador, la operación inversa de la que hace el ensamblador. Un desensamblador difiere de un decompilador, en que éste apunta a un lenguaje de alto nivel en vez de al lenguaje ensamblador. La salida de un desensamblador, el desensamblado, es a menudo formateada para la legibilidad humana en vez de ser adecuada para la entrada a un ensamblador, haciendo que éste sea principalmente una herramienta de ingeniería inversa. Algunos ejemplos. OllyDbg Es un depurador de código ensamblador de 32 bits para sistemas operativos Microsoft Windows. Pone especial énfasis en el análisis del código binario, esto lo

hace muy útil cuando no está dispone el código fuente del programa. Traza registros, reconoce procedimientos, llamadas a las API, swiches, tablas, constantes y strings, así como localiza rutinas de archivos objeto y de bibliotecas. De acuerdo con la ayuda incluida en el programa, la versión 1.10 es la última versión estable. La versión 2.0, que está en desarrollo, se está escribiendo desde cero. El software es libre de costo, pero la licencia shareware requiere que los usuarios se registren con el autor.2 Las versiones actuales de OllyDbg no pueden depurar ejecutables compilados para procesadores de 64 bits, aunque se ha prometido una versión de 64 bits del depurador. IDAPro. En informática, Interactive Disassembler (Desensamblador Interactivo), más conocido por su acrónimo IDA, es un desensamblador empleado para ingeniería inversa. Soporta una variedad de formatos ejecutables para diferentes procesadores y sistemas operativos. También puede ser usado como un depurador para ejecutables Windows PE, Mac OS X, Mach-O y Linux ELF. Un plugin de decompilador para programas compilados con C/C++ está disponible a un costo extra. La última versión completa del IDA Pro es un software comercial; una versión anterior y menos capaz está disponible para descarga gratuita (la versión 5.0 de noviembre de 2010). El IDA realiza mucho análisis automático del código, usando referencias cruzadas entre las secciones del código, conocimiento de parámetros de las llamadas del API, y otra información. Sin embargo, la naturaleza del desensamblado imposibilita una exactitud total, y una gran parte de intervención humana es necesariamente requerida; El IDA tiene funcionalidad interactiva para ayudar en la mejora del desensamblado. Un usuario típico del IDA comenzará con un listado de desensamblado automáticamente generado y después convertirá secciones de código a datos y viceversa, renombrará, anotará, y de otra manera agregará información al listado, hasta que se vuelve claro lo que lo hace. SoftICE. Es un depurador en modo kernel propietario y de pago para Microsoft Windows. Está diseñado para ejecutarse debajo de Windows, de tal manera que el Sistema Operativo desconozca su presencia. A diferencia de un depurador de aplicaciones, SoftICE es capaz de suspender todas las operaciones en Windows cuando se desee, lo cual resulta útil para depurar drivers ya que es importante conocer cómo se accede al hardware así como las funciones del sistema operativo.

MÓDULO 4. RESPUESTA ANTE INCIDENTES DE SEGURIDAD. UNIDAD DIDÁCTICA 1. PROCEDIMIENTO DE RECOLECCIÓN DE INFORMACIÓN RELACIONADA CON INCIDENTES DE SEGURIDAD. Un incidente de seguridad es cualquier evento que tenga o pueda tener como resultado la interrupción de los servicios suministrados por un sistema informático y/o posibles pérdidas físicas, de activos o financieras. La definición e implantación de un Plan de Respuesta a Incidentes debería tener en cuenta una serie de actividades y tareas, entre las cuales estaría la recolección de información sobre el incidente de seguridad, que explicaremos en esta unidad. A continuación exponemos brevemente cada una de las actividades o tareas del Plan de Respuesta a Incidentes:

Constitución de un Equipo de Respuesta a Incidentes: El Equipo de Respuesta a Incidentes de Seguridad Informática (CSIRT; Computer Security Incident 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 una organización. Generalmente solo las grandes organizaciones cuentan con un equipo de personas contratadas para cumplir con esta función; y en las organizaciones que no cuentan con un este equipo, será necesario identificar quiénes son las personas responsables de acometer cada una de las tareas del Plan de Respuesta a Incidentes. Estas personas deben contar con la dotación de medios técnicos y materiales necesarios para poder cumplir con eficacia su misión.

Definición de una Guía de Procedimientos: 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 comunicación de la organización, así como la recuperación de los datos dañados o destruidos. El objetivo de esta guía es conseguir una respuesta sistemática ante los incidentes de seguridad, realizando los pasos necesarios y en el orden adecuado para evitar errores ocasionados por la precipitación y la improvisación. Además, esta guía debe completar la adquisición de información detallada sobre cada incidente de seguridad y también debe tratar las cuestiones legales derivadas de cada incidente, y los aspectos relacionados con la imagen de la organización y las relaciones públicas.

Detección de un incidente de seguridad y recolección de información, para lo que será necesario observar los posibles indicadores de dicho incidente. Este punto lo desarrollaremos más ampliamente en el siguiente apartado.

Análisis del incidente: El Plan de Respuesta a 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 han podido ver afectados, si se ha podido comprometer información confidencial de la organización o de sus usuarios y clientes, si ha podido afectar a terceros, etc. A continuación, el equipo de respuesta debería determinar 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 exploradas, qué métodos ha empleado el atacante, etc. Además, conviene realizar 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., teniendo en cuenta para ello aspectos como el posible impacto del incidente en los recursos y servicios de la organización y en el desarrollo de su negocio o actividad principal.

Contención, erradicación y recuperación: El equipo de respuesta debe elegir una determinada estrategia de contención del incidente de seguridad, que podría ir desde llevar a cabo una rápida actuación para evitar que el incidente pueda tener mayores consecuencias hasta 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 (pero existe el riesgo de que el incidente pueda tener peores consecuencias).

Por otro lado, 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, además de llevar a cabo una revisión de otros sistemas que se pudieran ver comprometidos a través de las relaciones de confianza con el sistema afectado. En último lugar, en la etapa de recuperación se trata de restaurar los sistemas para que puedan volver a su normal funcionamiento.

Identificación del atacante y posibles actuaciones legales: La identificación del atacante es necesaria para poder llevar a cabo acciones legales para exigir responsabilidades y reclamar indemnizaciones. A pesar

de lo anterior, generalmente solo se podrá identificar la máquina o máquinas desde las que se ha llevado a cabo el ataque, pero no directamente a individuo responsable de su utilización. Existen distintas técnicas para determinar la dirección IP del equipo (o equipos) desde el que se ha llevado a cabo el ataque contra el sistema informático: utilización de herramientas como ping, traceroute o whois, consulta en los registros inversos de servidores DNS, etc.

Comunicación con terceros de la causa y las consecuencias del incidente y relaciones públicas: Se preverán los contactos con organismos de respuesta a incidentes de seguridad informática, con las fuerzas de seguridad, con agencias de investigación, con los servicios jurídicas de la organización, e incluso con proveedores de acceso a Internet y fabricantes de hardware y/o software que se hayan visto involucrados en el accidente. Además, también se contemplarán los contactos con terceros que pudieran haber sido perjudicados por el incidente de seguridad. También es importante tener en cuenta la existencia de normativa que puede obligar a la notificación de los incidentes de seguridad a determinados organismos de la Administración o ciudadanos afectados. Y por último, será conveniente definir un Plan de Comunicación con los Medios, en caso necesario.

Documentación del incidente de seguridad, entre la que podemos encontrar: la descripción del tipo de incidente, los hechos registrados, los daños producidos, las decisiones y actuaciones del equipo de respuesta, las comunicaciones realizadas con terceros y con los medios, la lista de evidencias obtenidas durante el análisis y la investigación, los comentarios e impresiones del personal involucrado y las posibles actuaciones y recomendaciones para reforzar la seguridad y evitar incidentes similares en el futuro.

Análisis y revisión a posteriori del incidente (verificación de la intrusión) para determinar qué ha aprendido la organización como consecuencia del incidente. Este apartado lo desarrollaremos en la unidad 3 de este módulo.

Recolección de información. Como una actividad a contemplar dentro del plan de respuesta a incidentes, para llevar a cabo una adecuada recolección de información, la organización debería prestar especial atención a los posibles indicadores de un incidente de seguridad.

A continuación presentamos una relación de los principales indicadores de posibles incidentes de seguridad:

- Precursores de un ataque: actividades previas de reconocimiento del sistema informático, como el escaneo de puertos o 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 un servidor, o modificaciones realizadas en determinado ficheros del sistema (librerías, aplicaciones críticas etc.), que se pueden detectar mediante herramientas de revisión de la integridad de ficheros.

- 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 usuario o registro de actividad inusual en

algunas cuentas: conexiones de usuarios en unos horarios extraños, utilización de la misma cuenta desde distintos equipos a la vez, bloqueo reiterado de cuentas por fallos en la autenticación, etc.

- Caída o mal funcionamiento de algún servidor: reinicios inesperados, fallos en algunos servicios, aparición de mensajes de error, incremento anormal de la carga del procesador o del consumo de memoria del sistema…

- Notable caída en el rendimiento de la red o de algún servidor, debido a un incremento inusual del tráfico de datos.

- 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 poco habituales o que consumen más recursos de los normales (tiempo, 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…

- Notificación de un intento de ataque lanzado contra terceros desde equipos pertenecientes a la propia organización.

- Desaparición de equipos de la 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 último caso podría ser, por ejemplo, dispositivos para la captura de pulsaciones de teclado en los equipos).

Conviene tener en cuenta que los ataques informáticos se están volviendo cada vez más sofisticados, por lo que es difícil conseguir detectarlos a tiempo. Incluso existen herramientas que facilitan este tipo de ataques ocultando su actividad y que se pueden obtener de forma gratuita en internet. Además, 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 provocado por los “falsos positivos”. Por este motivo, es necesario contar con herramientas y filtros que faciliten la detección y clasificación de los incidentes.

UNIDAD DIDÁCTICA 2. EXPOSICIÓN DE LAS DISTINTAS TÉCNICAS Y HERRAMIENTAS UTILIZADAS PARA EL ANÁLISIS Y CORRELACIÓN DE INFORMACIÓN Y EVENTOS DE SEGURIDAD. El grado actual de dependencia que los negocios y actividades tienen de las TIC (Tecnologías de la Información y la Comunicación) está forzando la integración de todos los procesos de seguridad. Las propias TIC son, además, el instrumento de apoyo necesario para detectar y registrar eventos, correlacionarlos, lanzar alarmas, prevenir, permitir la actividad forense y, en definitiva, crear inteligencia con fines de protección respetuosos con las leyes. Los Sistemas de Información y Comunicaciones se sitúan en un entorno complejo y cambiante, lleno de amenazas, que ponen en peligro la Seguridad de la Información que estos sistemas procesan, almacenan o transmiten. Para garantizar que estos sistemas se mantengan a un nivel de seguridad aceptable, es necesario conocer lo que está ocurriendo, dentro, fuera y en la frontera de los mismos:

Conocer la existencia de amenazas.

Determinar la probabilidad de materialización de las amenazas.

Conocer la materialización de la amenaza, un ataque, si este se produce.

Determinar el impacto real producido por el ataque, la materialización de la amenaza.

En la actualidad, los componentes de los Sistemas de Información y Comunicaciones, generan un gran número registros de eventos, que son almacenados en los ficheros de log, y solo determinados tipos de eventos generan una alarma, en muchos casos, únicamente cuando el ataque, es decir, la materialización de la amenaza, ha tenido éxito. El gran volumen de datos recopilados por los firewall, routers, sondas, IDS, sistemas antivirus, los propios servidores de la red y todos de elementos tanto hardware como software instalados en los sistemas, impide su análisis y proceso, en un tiempo razonable breve para que la información obtenida sea útil. Así, la única forma de obtener dicha información procesada en un tiempo útil, es disponer un Sistema de Análisis y Correlación de Eventos. Un adecuado Sistema de Análisis y Correlación de Eventos, permite:

Determinar, en tiempo real, la probabilidad de materialización de una amenaza en un instante dado.

Conocer, en tiempo real, cuando comienza un ataque al Sistema, permitiendo una alerta temprana.

Conocer si un ataque ha tenido éxito o no, y determinar el impacto real del mismo sobre el sistema.

Determinar los patrones de materialización de la amenazas, que serán utilizados posteriormente, para implantar nuevas salvaguardas o mejorar las existentes.

Si se es capaz de gestionar y analizar de forma adecuada la gran cantidad de volumen de datos de eventos de seguridad que proporcionan los sistemas, entonces se conocerá el nivel de seguridad de los sistemas y se tendrá la capacidad de prever los ataques y por tanto disminuir el número de impactos y la profundidad de los mismos. El tener conocimiento en tiempo real de lo que está ocurriendo en los sistemas, permitirá cumplir con las cuatro premisas de la seguridad:

Evitar: disminuir la probabilidad de materialización de la amenaza, evitando así que el ataque tenga éxito.

Retrasar: obligar a aumentar el umbral de duración del ataque (tiempo necesario para que este ataque tenga éxito).

Detectar el comienzo del ataque y tomar las medidas oportunas para minimizar su impacto.

Defender: responder activamente, recopilar información forense necesaria para la investigación del incidente y posterior persecución legal del responsable.

Por ello, todas las organizaciones deben contar con un Sistema de Análisis y Correlación de Eventos, que unido a un cuadro de mandos, les permita disponer de un conocimiento en tiempo real, del nivel de seguridad de sus Sistemas de Información y Comunicaciones, y adoptar las medidas necesarias para mantener dicho nivel por encima del mínimo requerido. Los Sistemas de Análisis y Correlación de Eventos de Seguridad, se han convertido en herramientas imprescindibles para una adecuada gestión de la seguridad de los Sistemas de Información, que contribuyen a la mejora de la calidad, al aumento de la eficiencia y eficacia de los sistemas, así como a incrementar el nivel de seguridad de la Información, uno de los activos más importantes de las organizaciones. Productos de gestión de eventos de seguridad. Son productos que permiten llevar a cabo la gestión de eventos o incidentes de seguridad en cualquiera de sus fases, ya sea antes, durante o después de que se

produzca un incidente. Recogen, cotejan y hacen informes con los datos de los registros de actividad (logs) de los dispositivos de seguridad o de red instalados en la red de área local (LAN): routers (enrutadores), switches (conmutadores), cortafuegos, UTMs,… Así mismo, permiten establecer un flujo para la gestión de los eventos de seguridad de forma que sea posible tratar los incidentes de forma organizada y siguiendo un procedimiento cuyo objetivo es la resolución del incidente en el menor tiempo posible y con las menores consecuencias para las organizaciones. Son herramientas que posibilitan actuar en la prevención, detección, mitigación, análisis y aplicación de contramedidas. Subcategorías.

Gestión de eventos de seguridad (SEM – Securitiy Event Managment). Son herramientas destinadas a dar respuesta a incidentes de seguridad, apoyando a las organizaciones en cualquiera de las fases de un evento de seguridad. Sus beneficios incluyen el envío de todos los eventos a un sistema centralizado que va a permitir: acceder a todos los logs (registros de actividad) con un interfaz único, proveer un sistema de archivo y almacenamiento seguro de los registros de los distintos eventos, generar informes para extraer de los logs la información útil, seguir e investigar los eventos según su importancia con la emisión de alertas y notificaciones a los agentes y actuadores interesados, detectar eventos en múltiples sistemas, proteger ante un borrado intencional o accidental de los logs.

Ofrece una monitorización y gestión de eventos en tiempo real. Funcionan recogiendo información (registros de actividad o logs) de todos los sistemas y equipos supervisados, agregándola y correlacionándola aproximadamente en tiempo real. Mediante una consola es posible la visualización, monitorización y gestión de eventos mediante reglas para detectar situaciones anómalas y mecanismos para automatizar la respuesta en caso de incidentes.

Gestión de información de seguridad (SIM - Security Information Management). Son sistemas de supervisión cuya funcionalidad es la recolección, correlación y análisis de información de seguridad en diferido, es decir, creando un repositorio indexado con datos obtenidos de los dispositivos supervisados. Este repositorio permite ser interrogado para generar informes con los que obtener perspectiva general de la seguridad del entorno supervisado, detectar riesgos, revisar el cumplimiento normativo y actuar en consecuencia. Permiten la gestión del ciclo de vida de la

información, protegiéndola con garantías de seguridad en su vida útil y garantizando su destrucción cuando esta termina. SIM es la pieza clave de cualquier planteamiento en la gestión de la seguridad lógica. El creciente número de gusanos, virus, hackers e intrusos, hace que las empresas adopten mejores infraestructuras de seguridad para protegerse. Pero al intervenir grandes sumas de dinero en un amplio abanico de soluciones de seguridad como antivirus, firewalls y sistemas de detección de intrusiones, las empresas se han expuesto al problema de la complejidad. Para poner solución a esto se diseñó ArcSight, un sistema de correlación de eventos de seguridad. Esta herramienta permite centralizar, almacenar y correlacionar la información generada por herramientas heterogéneas mejorando, de este modo, la detección de intrusiones y la gestión de incidentes de seguridad. Hoy en día, este tipo de herramientas se está convirtiendo en una pieza indispensable en la implementación de Sistemas de Gestión de Seguridad Informática (SGSI), ofreciendo la posibilidad de generar de manera automática estadísticas y métricas de seguridad para completar los tan deseados cuadros de mando de la gerencia. ArcSight ha desarrollado también una lista de buenas prácticas de evaluación para ayudar a las empresas a hacer la elección acertada de un sistema SIM, teniendo en consideración su entorno.

Gestión de información y eventos de seguridad (SIEM - Security Information and Event Management). Son sistemas con la funcionalidad añadida de SIM y SEM. Es decir recogen o reciben logs (registros de actividad) de todos los dispositivos que monitorizan, almacenándolos y conservándolos a largo plazo (cifrados, firmados, etc.) y agregan y correlacionan en tiempo real la información recibida para permitir la detección y actuación sobre los eventos, con alertas, respuesta automatizada, informes adecuados a distintas normativas, etc.

En definitiva, SIEM es una solución que ayuda a detectar y a seguir la pista de posibles ataques y no perderse entre los innumerables logs y alertas de los heterogéneos sistemas. Ayudarán a identificar y responder a ataques que podrían pasar desapercibidos por los IDS convencionales. Y además, también ayudan a administrar y archivar los logs más fácilmente y a generar valiosos informes. No solucionarán todos los problemas de seguridad, pero se trata de métodos efectivos para una "defensa en profundidad". Uno de los elementos principales en los que se basa la gestión de riesgos de seguridad de la información es, sin duda, el análisis y la gestión de logs

(registros) y la correlación de eventos, lo que se entiende por SIEM. La confluencia de este pilar de la seguridad con el de la gestión de identidades y accesos a sistemas, redes y aplicaciones, la gestión de documentos y la gestión de evidencias, permitiría al responsable de seguridad TIC alcanzar su objetivo específico en la cadena de protección: saber en tiempo real qué está pasando en los sistemas tecnológicos que pueda ser relevante para su seguridad, para la de la información que tratan, y, en definitiva, para el negocio y actividades de su entidad. Las plataformas SIEM han tenido un desarrollo rápido en los últimos años, y constituyen hoy la base de proyectos de obligado emprendimiento para cualquier organización de cierta complejidad y bien gobernada. Sin embargo, la multicanalidad de las acciones fraudulentas y de los comportamientos no acordes con las políticas de seguridad, y el enfoque de la protección como un proceso integrado que afecta a la seguridad TIC y a la seguridad física, obliga a analizar detalladamente qué se quiere y puede monitorizar, a qué nivel, con qué reglas de correlación y para qué fines. Así, esto obliga a la industria y a los desarrolladores a refinar sus herramientas para que se ajusten en lo posible a las necesidades crecientes de los usuarios y a los requisitos legales. Pero hay que tener en cuenta que nos dirigimos hacia un escenario marcado por la centralización de procesos esenciales de seguridad en SOC y CERT, y hacia servicios con base en TIC fundamentados en el uso de técnicas de virtualización y en XaaS. Si a ello se suma el uso intensivo de las tecnologías de la información en la vigilancia tradicional y en la prevención de fraude, y si se toma conciencia de la dependencia que tienen de las TIC los sistemas de gestión y control de procesos industriales (scada), puede observarse la nueva dimensión de la correlación de eventos con fines de seguridad.

Ha de tenerse presente que estos son productos que pueden requerir un mantenimiento continuo y debido a que interactúan con distintos tipos de infraestructuras es fundamental que estas herramientas sean revisadas y se mantengan actualizadas constantemente. Su escenario de aplicación es fundamentalmente en organizaciones y empresas de cualquier tamaño. Allí donde existan procesos y actividades críticas e importantes para el buen funcionamiento de una organización o empresa, es recomendable contar con este tipo de herramientas. Así mismo, son fundamentales en organizaciones que cuenten con infraestructuras tecnológicas importantes tanto por tamaño como por dependencia de las mismas, puesto que

ayudan a la gestión de todos los aspectos relativos a la seguridad, minimizando cualquier incidente que se pueda producir.

UNIDAD DIDÁCTICA 3. PROCESO DE VERIFICACIÓN DE LA INTRUSIÓN. Dentro del Plan de Respuesta a Incidentes se debe tener en cuenta una etapa para el análisis y revisión a posteriori de cada incidente de seguridad, es decir, una verificación de la intrusión, con el fin de determinar qué ha podido aprender la organización como consecuencia del mismo. Para ello, será necesario elaborar un informe final sobre el incidente, en el que se desarrollen los siguientes aspectos de forma detallada:

Investigación sobre las causas y consecuencias del incidente: o Estudio de la documentación generada por el equipo de respuesta a

incidentes. o Revisión detallada de los registros de actividad (logs) de los

ordenadores y dispositivos afectados por el incidente. o Evaluación del coste del incidente de seguridad para la organización:

equipos dañados, software 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, etc.

o Análisis de las posibles consecuencias para terceros. o Revisión del intercambio de información sobre el incidente con otras

empresas e instituciones, así como con los medios de comunicación. o 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:

o Composición y organización del equipo, incluyendo la formación y nivel de desempeño de sus miembros.

o Rapidez en las actuaciones y decisiones, teniendo en cuenta cómo respondió el personal involucrado en el incidente, qué tipo de información se obtuvo para gestionar el incidente, qué decisiones se adoptaron, etc.

o Análisis de los procedimientos y de los medios técnicos empleados en la respuesta al incidente:

Redefinición de los 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.

o 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 su sistema informático.

UNIDAD DIDÁCTICA 4. NATURALEZA Y FUNCIONES DE LOS ORGANISMOS DE GESTIÓN DE INCIDENTES TIPO CERT NACIONALES E INTERNACIONALES. En la actualidad, las tecnologías de la información se han convertido en una herramienta de gran utilidad presente en la mayor parte de los aspectos de nuestra vida cotidiana, haciéndose en muchos casos imprescindibles para el desarrollo de nuestras tareas. El desarrollo y generalización de las tecnologías de la información y la comunicación (TIC) también implica la necesidad de solucionar problemas de seguridad, ataques y posibles vulnerabilidades que surgen consigo. Así, para combatir de forma más eficaz las distintas amenazas que afectan a la seguridad de los sistemas informáticos, en estos últimos años se han creado varios organismos especializados cuya misión es alertar a los gobiernos, empresas y ciudadanos en general para poder contener y minimizar los daños ocasionados por los ataques informáticos. Con esta idea surgen los CERTs. Se denomina CERT (Computer Emergency Response Team, Equipo de respuesta ante emergencias informáticas) a un conjunto de personas responsable del desarrollo de medidas preventivas y reactivas ante incidencias de seguridad en los sistemas de información de la comunidad a la que se proporciona el servicio. También se puede utilizar el término CSIRT (Computer Security Incident Response Team, Equipo de respuesta ante incidencias de seguridad) para referirse al mismo concepto. Los CERT o CSIRT prestan sus servicios para un área de cobertura definida que podría ser una entidad relacionada u organización de la cual dependen, una corporación, una organización de gobierno o educativa; una región o país, una red de investigación; o un servicio pago para un cliente. A grandes rasgos podemos dividir las funciones de un CERT/CSIRT en:

Servicios reactivos: Estos servicios se inician ante un evento o pedido, tal como un informe de un ordenador comprometido, código malicioso ampliamente diseminado, vulnerabilidad de software, o algo que fue identificado por un sistema de detección de intruso o un sistema de registro de eventos. Los servicios reactivos son el componente central del trabajo de un CERT/CSIRT.

Servicios proactivos: Estos servicios ofrecen asistencia e información para ayudar a preparar, proteger y asegurar los sistemas de los miembros del

área de cobertura, anticipando ataques, problemas o eventos. Estos servicios reducirán directamente la cantidad de incidentes en el futuro.

Servicios de gestión de calidad de la seguridad: Estos servicios aumentan los servicios existentes y bien establecidos que son independientes del manejo de incidentes y tradicionalmente llevados a cabo por otras áreas de una organización tales como Tecnología de la Información (IT), auditoría o departamentos de capacitación.

El primer CERT se creó en 1988 en la Universidad Carnegie Mellon, en Estados Unidos (propietaria de esta marca registrada), y desde entonces han ido creándose este tipo de Equipos en todo el mundo y en distintos ámbitos de la sociedad (Administración, Universidad, investigación, empresa, etc.). A continuación explicamos algunos de estos organismos de gestión de incidentes. Cert/CC (Computer Emergency Response Team / Coordination Center). El CERT, el “Equipo de Respuesta a Emergencias Informáticas”, es el primer y más conocido centro de respuesta, creado en diciembre de 1988 por la agencia DARPA de Estados Unidos para gestionar los incidentes de seguridad relacionados con Internet. Se encuentra en el Instituto de Ingeniería del Software de la Universidad Carnegie Mellon. CERT INTECO. El Centro de Respuesta a Incidentes de Seguridad fue creado a mediados de 2007 en España dentro del Instituto Nacional de Tecnologías de la Información (INTECO). La finalidad de INTECO-CERT es servir de apoyo preventivo y reactivo en materia de seguridad en tecnologías de la información y la comunicación tanto a entidades como a ciudadanos. Tiene vocación de servicio público sin ánimo de lucro y ofrece ayuda que, en todos los casos, es gratuita y de rápida gestión. Sirve de apoyo al desarrollo del tejido industrial nacional y ofrece los servicios clásicos de un Centro de Respuesta a Incidentes, dando soluciones reactivas a incidentes de seguridad informáticos, servicios de prevención frente a posibles amenazas y servicios de información, concienciación y formación en materia de seguridad.

INTECO-CERT surge como iniciativa pública para pymes y ciudadanos en materia de seguridad con los siguientes objetivos en materia de seguridad:

Concienciar en torno al uso seguro de las TIC.

Formar en materia de seguridad.

Informar sobre virus, vulnerabilidades y otros temas relacionados con la seguridad.

Proteger: orientar sobre útiles gratuitos, actualizaciones, recomendaciones, etc.

Ayudar y asesorar cuando surge un problema de seguridad. Agencia Europea de Seguridad de las Redes y de la Información. La Agencia Europea fue creada por decisión del Consejo y del Parlamento (EC 460/2004) con la finalidad de alcanzar un alto nivel de seguridad en las redes y en el tratamiento de la información dentro de la Unión Europea. Esta Agencia comenzó oficialmente sus actividades en septiembre de 2005, tras fijar su sede institucional en la isla de Creta. CSRC (Computer Security Resource Center). El CSRC, “Centro de Recursos de Seguridad Informática”, es un centro dependiente del NIST (National Institute Standards of Technology de Estados Unidos). US-CERT. El US.CERT es un Centro de Respuesta a Incidentes de Seguridad Informática que depende del National Cyber Security Division (NCSD) en el Departamento de Seguridad Interior (Department of Homeland Security (DHS)) de Estados Unidos. Otros centros de seguridad y respuesta a incidentes. Otros países también han puesto en marcha sus respectivos centros de respuesta a incidentes de seguridad, como AusCERT (Australian Computer Emergency Response Team) de Australia o el DFN-CERT (Computer Emergency Response Team for the German Research Network) de Alemania. Otros centros de seguridad y respuesta a incidentes en España. En España también podemos destacar los servicios del IRIS-CERT, Centro de Respuesta a Incidentes de Seguridad de la Red IRIS, que da soporte a los Centros de Investigación y Universidades del país.

En nuestro país también, el CCN-CERT es la Capacidad de Respuesta a incidentes de Seguridad de la Información del Centro Criptológico Nacional (CCN), dependiente del Centro Nacional de Inteligencia (CNI). Este servicio se creó en 2006 como CERT gubernamental español y su principal objetivo es contribuir a la mejora del nivel de seguridad de los sistemas de la información de las tres administraciones públicas existentes en España (general, autonómica y local) y coordinar, a nivel público estatal, los distintos equipos de respuesta, tal y como recoge el RD 3/2010 (ENS) en sus artículos 36 y 37. Tiene responsabilidades, en ciberataques clasificados, sistemas de las distintas administraciones públicas y, en coordinación con el CNPIC, sobre sistemas que gestionen infraestructuras críticas. Además, el Centro de Alerta Temprana sobre Virus y Seguridad Informática fue creado en julio de 2001 por el Ministerio de Ciencia y Tecnología español, para ofrecer información, alertas y distintos recursos sobre seguridad informática a ciudadanos y empresas. En la actualidad se encuentra integrado dentro de INTECO. A parte de los indicados anteriormente, otros CERT y centros operativos de seguridad en nuestro país son: CSIRT-CV (Centro de Seguridad TIC de la Comunidad Valenciana), el Centre de Seguretat de la Informació de Catalunya, Andalucía-CERT, es-CERT (Universidad Politécnica de Cataluña), e-la Caixa-CSIRT, Mapfre CCG-CERT, S21Sec-CERT, TB-Security-CERT…. Foros y organizaciones. Además de los CERT, también han surgido distintos foros y organizaciones que coordinan a los diferentes CSIRTs y CERTs de todo el mundo, compartiendo información sobre vulnerabilidades y ataques a nivel global y divulgando medidas tecnológicas que mitiguen el riesgo de ataques a sistemas y usuarios conectados a Internet, que dan servicio a sus respectivas comunidades. Entre estas organizaciones, destacan el FIRST (Forum of Incident Response and Security Teams), que cuenta con más de 180 miembros de todo el mundo. Es un foro constituido en 1990 con el objetivo de facilitar el intercambio de información sobre incidentes de seguridad entre los distintos miembros que lo integran (Centros de Respuesta a Incidentes de distintos países y organizaciones), así como para la detección, prevención y recuperación de estos incidentes de seguridad. A nivel europeo, podemos indicar el Trusted Introducer de TERENA (Asociación Transeuropea de Investigación y Educación de Redes) y el EGC Group (European Government CERTs) que reúne a los principales CERTs gubernamentales en Europa.

Bases de datos de ataques e incidentes de seguridad. También existen distintos organismos que se encargan de capturar y agrupar los registros de incidiencias (logs) y ataques sufridos por distintas organizaciones en una base de datos. DShield (Distributed Intrusion Detection System, Sistema de Detección de Intrusiones Distribuido) es una de las bases de datos sobre incidentes de seguridad informática más conocida. Otra completa base de datos con referencias sobre incidentes de seguridad se encuentra disponible en Security Focus. Así mismo, también podemos encontrar algunos servicios que se encargan de evaluar el estado del tráfico en Internet, como Internet Health Monitoring, que contribuye a la detección y control de los ataques de Denegación de Servicio (DoS)

MÓDULO 5. PROCESO DE NOTIFICACIÓN Y GESTIÓN DE INTENTOS DE INTRUSIÓN. UNIDAD DIDÁCTICA 1. ESTABLECIMIENTO DE LAS RESPONSALIBILIDADES EN EL PROCESO DE NOTIFICACIÓN Y GESTIÓN DE INTENTOS DE INTRUSIÓN O INFECCIONES. Una intrusión es cualquier evento intencional a través del cual un intruso que gana acceso compromete la confidencialidad, integridad o disponibilidad de los computadores, las redes o de los datos-información-conocimiento que reside en ellos. Un atacante o adversario o intruso o hacker puede engañar a un firewall y robar ficheros secretos situados en un servidor, la solución es utilizar algún tipo de sistema de detección-prevención-gestión de intrusiones. En este sentido, vamos a analizar a continuación la efectividad y los criterios para la elección de un sistema IDS o IPS. Medida de la efectividad de los IDS/IPS. Dos métricas dominantes utilizadas para evaluar IDS/IPS son:

Los administradores evalúan el número de ataques detectados sobre un conjunto conocido de pruebas.

Los administradores examinan el nivel de utilización en cada IDS con fallo. La evaluación de un IDS puede expresarse de la siguiente forma, por ejemplo a 1000 Mbps un IDS puede detectar el 97% de ataques dirigidos. Debido a que desarrollar esta recogida puede ser tediosa, la mayor parte de fabricantes de IDS proporcionan mecanismos de test para verificar que los sistemas están rindiendo como se espera de ellos. Algunos de estos procesos de test permitirán al administrador: (i) Registrar y retransmitir paquetes desde escaners de virus o gusanos reales. (ii) Registrar y transmitir paquetes desde escaners de virus y gusanos reales con conexiones de sesión TCP incompletas (perdiendo paquetes SYN). (iii) Realizar un escaneo de virus o gusanos reales contra un sistema invulnerable.

Criterios a la hora de elegir un IDS/IPS. A la hora de elegir un IDS se pueden considerar las siguientes directrices o criterios de valoración:

Firmas de ataque utilizadas. Se debe valorar su calidad y el organismo que las crea; se debe examinar la tasa de falsos positivos, de falsos negativos así como la BRF (Base Rate Fallacy). Así mismo, se debe considerar la frecuencia de su actualización (si es mayor de ocho horas puede ser peligroso). Además es conveniente valorar el mecanismo de actualización (si está protegido y en qué consiste).

Escalabilidad. Se debe valorar la capacidad de gestión y manipulación de tráfico se debe observar si cuenta con funcionalidades de balanceo de carga para horas punta. Así mismo en HIDS las plataformas soportadas. Otro aspecto para poder valorar con criterio es el tipo de mecanismo de shutdown (para apagar) utilizado.

El tipo de plataforma hardware utilizada. Por ejemplo sobre un PC o sobre un appliance switch con procesadores de propósito general como procesadores basados en Intel (por ejemplo Intel Core 2 Quad), bien basada en procesadores sparc, bien basada en hardware ASIC (Application-Specific Integrated Circuits, circuitos integrados que realizan un conjunto de instrucciones codificadas en hardware sobre los datos que pasan), bien basada en hardware FPGA (Field Programmable Gate Arrays, circuitos integrados que pueden programarse para realizar ciertas operaciones sobre los datos que pasan).

Capacidad de administración o gestionabilidad. Se pueden examinar si incorpora funcionalidades como: capacidad de examen de log, referencias cruzadas, capacidad de archivo, existencia de consola centralizada. Algunos de los problemas potenciales que presentan los IDS/IPS: la calidad de las firmas de ataque; la gestión de tráfico cifrado SSL, los túneles IPSEC/PPTP, los adjuntos PGP en correo electrónico; el uso de LANs con switch (múltiples dominios de colisión) frente a LANs con hub (un dominio de colisión) exige realizar conexiones a través del puerto de spanning/mirroring de switch para monitorizar todo el tráfico, posible degradación del rendimiento; el despliegue en redes de muy alta velocidad puede darse la no monitorización de todo el tráfico.

Obligación legal de notificación de ataques e incidencias. Una vez analizadas las responsabilidades de los sistemas de detección y prevención de intrusiones en relación a la efectividad que pueden mostrar, y en cuanto a los criterios más óptimos para su elección; analizamos desde un punto de vista legislativo, un ejemplo de responsabilidad legal en la notificación de intrusiones o infecciones. La obligación de notificación de ataques e incidencias que puedan afectar a la seguridad informática es una medida que ya ha sido adoptada por el Estado de California en Estados Unidos. Así, en este estado desde el 1 de Julio de 2003 todos los “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 su sistema informático. De hecho la “Sennate bill 1386” fue aprobada en California en Septiembre de 2002 después de que tuviese lugar una intrusión en los sistemas de nóminas de Estado, a consecuencia de la cual los datos de más de doscientos mil empleados del Estado cayeron en manos de los atacantes, con un notable riesgo de fraudes y robos de identidad. En virtud de lo dispuesto por esta ley, toda empresa afectada por un ataque o incidencia informática deberá informar de este hecho por correo electrónico a sus clientes, indicándoles que el número de su tarjeta de crédito o algún otro dato de carácter personal podría haber sido sustraído de los ordenadores de la empresa. Esta alerta informativa 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. Esta ley del Estado de California no contempla la aplicación de multas a quienes no cumplan con este requisito, pero sí abre las puertas a todo tipo de procesos legales contra las empresas afectadas. En la actualidad se estudia la posibilidad de aplicar esta misma medida a todas las empresas que cotizan en bolsa en Estados Unidos. En España, lo más cercano legislativamente a lo planteado anteriormente es la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, que además es complementada por el Real Decreto 994/99 de 11 de junio, que establece las medidas de seguridad de los ficheros automatizados que contengan datos de carácter personal.

UNIDAD DIDÁCTICA 2. CATEGORIZACIÓN DE LOS INCIDENTES DERIVADOS DE INTENTOS DE INTRUSIÓN O INFECCIONES EN FUNCIÓN DE SU IMPACTO POTENCIAL. A la hora de estudiar los distintos tipos de ataques informáticos, podríamos diferenciar en primer lugar entre los ataques activos, que producen cambios en la información y en la situación de los recursos del sistema, y los ataques pasivos, que se limitan a registrar el uso de los recursos y/o a acceder a la información guardada o transmitida por el sistema. Seguidamente se presenta una relación más detallada de los principales tipos de ataques contra redes y sistemas informáticos y la categorización de los incidentes provocados: Actividades de reconocimiento de sistemas. Estas actividades directamente relacionadas con los ataques informáticos, si bien no se consideran ataques como tales ya que no provocan ningún daño, persiguen obtener información previa sobre las organizaciones y sus redes y sistemas informáticos, realizando para ello un escaneo de puertos para determinar qué servicios se encuentran activos o bien un reconocimiento de versiones de sistemas operativos y aplicaciones, por citar dos de las técnicas más conocidas. Detección de vulnerabilidades en los sistemas. Este tipo de ataques tratan de detectar y documentar las posibles vulnerabilidades de un sistema informático, para a continuación desarrollar alguna herramienta que permita explotarlas fácilmente (herramientas conocidas popularmente como “exploits”). Robo de información mediante la interceptación de mensajes. Ataques que tratan de interceptar los mensajes de correo o los documentos que se envían a través de redes de ordenadores como Internet, vulnerando de este modo la confidencialidad del sistema informático y la privacidad de sus usuarios. Modificación del contenido y secuencia de los mensajes transmitidos. En estos ataques los intrusos tratan de reenviar mensajes y documentos que ya habían sido previamente transmitidos en el sistema informático, tras haberlos modificado de forma maliciosa (por ejemplo, para generar una nueva transferencia bancaria contra la cuenta de la víctima del ataque). También se conocen como “ataques de repetición” (“replay attacks”).

Análisis del tráfico. Estos ataques persiguen observar los datos y el tipo de tráfico transmitido a través de redes informáticas, utilizando para ello herramientas como los “sniffers”. Así, se conoce como “eavesdropping” a la interceptación del tráfico que circula por una red de forma pasiva, sin modificar su contenido. Una organización podría protegerse frente a los “sniffers” recurriendo a la utilización de redes conmutadas (“switches” en lugar de “hubs”) y de redes locales virtuales (VLAN). No obstante, en redes locales que utilizan “switches” (es decir, en redes conmutadas), un atacante podría llevar a cabo un ataque conocido como “MAC flooding” para provocar un desbordamiento de las tablas de memoria de un switch (tablas denominadas CAM por los fabricantes, “Content Addresable Memory”) para conseguir que pase a funcionar como un simple “hub” y retransmita todo el tráfico que recibe a través de sus puertos (al no poder “recordar” qué equipos se encuentran conectados a sus distintas bocas o puertos por haber sido borradas sus tablas de memoria). Por otra parte, en las redes VLAN (redes locales virtuales) un atacante podría aprovechar el protocolo DTP (Dynamic Trunk Protocol), utilizado para poder crear una VLAN que atraviese varios switches, para intentar saltar de una VLAN a otra, rompiendo de este modo el aislamiento físico impuesto por la organización para separar sus distintas redes locales. Ataques de suplantación de la identidad. IP Spoofing Los ataques de suplantación de la identidad presentan varias posibilidades, siendo una de las más conocidas la denominada “IP Spoofing” (“enmascaramiento de la dirección IP”), mediante la cual un atacante consigue modificar la cabecera de los paquetes enviados a un determinado sistema informático para simular que proceden de un equipo distinto al que verdaderamente los ha originado. Así, por ejemplo, el atacante trataría de seleccionar una dirección IP correspondiente a la de un equipo legítimamente autorizado para acceder al sistema que pretende ser engañado. En el documento RFC 2267 se ofrece información detallada sobre el problema del “IP Spoofing”. Los propietarios de las redes y operadores de telecomunicaciones podrían evitar en gran medida el “IP Spoofing” implantando filtros para que todo el tráfico saliente

de sus redes llevara asociado una dirección IP de la propia red desde la que se origina el tráfico. Otro posible ataque sería el secuestro de sesiones ya establecidas (“hijacking”), donde el atacante trata de suplantar la dirección IP de la víctima y el número de secuencia del próximo paquete de datos que va a transmitir. Con el secuestro de sesiones se podrían llevar a cabo determinadas operaciones en nombre de un usuario que mantiene una sesión activa en un sistema informático como, por ejemplo, transferencias desde sus propias cuentas corrientes si en ese momento se encuentra conectado al servidor de una entidad financiera. DNS Spoofing Los ataques de falsificación de DNS pretenden provocar un direccionamiento erróneo en los equipos afectados, debido a una traducción errónea de los nombres de dominio a direcciones IP, facilitando de este modo la redirección de los usuarios de los sistemas afectados hacia páginas Web falsas o bien la interceptación de sus mensajes de correo electrónico. Para ello, en este tipo de ataque los intrusos consiguen que un servidor DNS legítimo acepte y utilice información incorrecta obtenida de un ordenador que no posee autoridad para ofrecerla. De este modo, se persigue “inyectar” información falsa en la base de datos del servidor de nombres, procedimiento conocido como “envenenamiento de la caché del servidor DNS”, ocasionando con ello serios problemas de seguridad, como los que se describen de forma más detallada a continuación:

Redirección de los usuarios del servidor DNS atacado a Websites erróneos en Internet, que simulan ser los Websites reales. De este modo, los atacantes podrían provocar que los usuarios descargasen de Internet software modificado en lugar del legítimo (descarga de código dañino, como virus o troyanos, desde Websites maliciosos).

La manipulación de los servidores DNS también podría estar detrás de algunos casos de “phishing”, mediante la redirección de los usuarios hacia páginas Web falsas creadas con la intención de obtener datos confidenciales, como sus claves de acceso a servicios de banca electrónica.

Otra posible consecuencia de la manipulación de los servidores DNS serían los ataques de Denegación de Servicio (DoS), al provocar la redirección permanente hacia otros servidores en lugar de hacia el verdadero, que de

este modo no podrá ser localizado y, en consecuencia, visitado por sus legítimos usuarios.

Los mensajes de correo podrían ser redirigidos hacia servidores de correo no autorizados, donde podrían ser leídos, modificados o eliminados. Para ello, basta con modificar el registro MX (“Mail Exchanger”) de la tabla de datos del servidor DNS atacado.

Por otra parte, un servidor DNS afectado por este tipo de ataque podría provocar falsas respuestas en los restantes servidores DNS que confíen en él para resolver un nombre de dominio, siguiendo el modelo jerárquico del servicio DNS, extendiendo de este modo el alcance del ataque de “DNS Spoofing”. SMTP Spoofing. El envío de mensajes con remitentes falsos (“masquerading”) para tratar de engañar al destinatario o causar un daño en la reputación del supuesto remitente es otra técnica frecuente de ataque basado en la suplantación de la identidad de un usuario. De hecho, muchos virus emplean esta técnica para facilitar su propagación, al ofrecer información falsa sobre el posible origen de la infección. Asimismo, este tipo de ataque es muy utilizado por los “spammers”, que envían gran cantidad de mensajes de “correo basura” bajo una identidad falsa. En la actualidad, falsificar mensajes de correo resulta bastante sencillo porque el protocolo SMTP carece totalmente de autenticación. Así, un servidor configurado para aceptar conexiones SMTP en el puerto 25 podría ser utilizado por un usuario externo a la organización, empleando los comandos propios del protocolo, para que envíe mensajes que aparenten tener un origen seleccionado por el atacante cuando realmente tienen otro distinto. La dirección de origen puede ser una dirección existente o una inexistente con el formato adecuado. No obstante, los servidores de correo también podrían ser configurados para no aceptar envíos de mensajes desde equipos externos a la red local. Captura de cuentas de usuario y contraseñas. También es posible suplantar la identidad de los usuarios mediante herramientas que permitan capturar sus contraseñas, como los programas de software espía o los dispositivos hardware especializados que permitan registrar todas las pulsaciones en el teclado de un ordenador (“keyloggers”). De hecho, es posible localizar soluciones disponibles en el mercado como KeyGhost (www.keyghost.com) o Key- Logger (www.keylogger.com).

Se conoce como “snooping” a la técnica que permite observar la actividad de un usuario en su ordenador para obtener determinada información de interés, como podrían ser sus contraseñas. Los programas que permiten realizar esta actividad se conocen con el nombre de “snoopers”, los cuales pueden ser troyanos u otros “parásitos” que monitorizan dispositivos de entrada como los ratones y los teclados. Por otra parte, mediante las técnicas de “Ingeniería Social” un usuario podría ser engañado por una persona ajena a la organización para que le facilite sus contraseñas y claves de acceso. Modificaciones del tráfico y de las tablas de enrutamiento. Los ataques de modificación del tráfico y de las tablas de enrutamiento persiguen desviar los paquetes de datos de su ruta original a través de Internet, para conseguir, por ejemplo, que atraviesen otras redes o equipos intermedios antes de llegar a su destino legítimo, para facilitar de este modo las actividades de interceptación de datos. Así, la utilización del encaminamiento fuente (“source routing”) en los paquetes IP permite que un atacante pueda especificar una determinada ruta prefijada, que podría ser empleada como ruta de retorno, saltándose todas las reglas de enrutamiento definidas en la red. De este modo, utilizando además el “IP Spoofing”, un atacante se podría hacer pasar por cualquier máquina en la que el destino pueda confiar, para recibir a continuación los datos correspondientes al equipo que está suplantando. También es posible llevar a cabo una modificación de las tablas de enrutamiento, utilizando para ello determinados paquetes de control del tráfico, conocidos como paquetes “ICMP Redirect” , que permiten alterar la ruta a un determinado destino. Otra alternativa sería la de modificar las rutas a través de los propios protocolos de enrutamiento utilizados, como RIP (puerto UDP 520) o BGP. Al modificar las rutas, el tráfico atravesará otros equipos y redes antes de alcanzar su destinatario final, facilitando de este modo el “sniffing”.

Conexión no autorizada a equipos y servidores. Existen varias posibilidades para establecer una conexión no autorizada a otros equipos y servidores, entre las que podríamos destacar las siguientes:

Violación de sistemas de control de acceso.

Explotación de “agujeros de seguridad” (“exploits”).

Utilización de “puertas traseras” (“backdoors”), conjunto de instrucciones no documentadas dentro de un programa o sistema operativo, que permiten acceder o tomar el control del equipo saltándose los controles de seguridad.

Utilización de “rootkits”, programas similares a los troyanos, que se instalan en un equipo reemplazando a una herramienta o servicio legítimo del sistema operativo. Los “rootkits”, además de cumplir con las funciones de la herramienta o servicio que reemplazan en el equipo para no despertar sospechas, incorporan otras funciones ocultas que facilitan, entre otras cosas, el control remoto del equipo comprometido.

“Wardialing”: conexión a un sistema informático de forma remota a través de un módem. Los “wardialers” son dispositivos que permiten realizar de forma automática multitud de llamadas telefónicas para tratar de localizar módems que se encuentren a la espera de nuevas conexiones y que no hayan sido protegidos y configurados de forma adecuada.

Tampoco debemos olvidar las posibles pérdidas o robos de equipos que contienen información sensible y que, por este motivo, puedan caer en manos de personas ajenas a la organización, las cuales podrían tratar de tomar el control de estos equipos para extraer la información que almacenan o para utilizarlos en conexiones remotas a la red de la organización. Consecuencias de las conexiones no autorizadas a los sistemas informáticos. Las conexiones no autorizadas a los sistemas informáticos pueden acarrear graves consecuencias para la organización afectada por este tipo de ataques e incidentes, entre las que podríamos destacar las siguientes:

Acceso a información confidencial guardada en un servidor. Los atacantes incluso podrían tener acceso a datos y ficheros que habían sido “borrados” del sistema.

Utilización inadecuada de determinados servicios por parte de usuarios no autorizados, suponiendo una violación de los permisos establecidos en el sistema.

Transmisión de mensajes mediante un servidor de correo por parte de usuarios ajenos a la organización (“mail relaying”). Esto podría facilitar el reenvío masivo de mensajes de spam a través de un servidor SMTP configurado de forma inadecuada.

Utilización de la capacidad de procesamiento de los equipos para otros fines, como, por ejemplo, para tratar de romper las claves criptográficas de otros sistemas.

Creación de nuevas cuentas de usuario con privilegios administrativos, que faciliten posteriores accesos al sistema comprometido.

Consumo del ancho de banda de la red de la organización para otros fines.

Almacenamiento de contenidos ilegales en los equipos: muchos atacantes aprovechan los equipos comprometidos de una organización para guardar y distribuir copias piratas de software, canciones o vídeos, pornografía infantil.

Modificación o destrucción de archivos y documentos guardados en un servidor.

“Website vandalism”: modificación del contenido y de la apariencia de unas determinadas páginas Web pertenecientes a la organización.

Introducción en el sistema de “malware” (código malicioso). Entendemos por código malicioso o dañino (“malware”) cualquier programa, documento o mensaje susceptible de causar daños en las redes y sistemas informáticos. Así, dentro de esta definición estarían incluidos los virus, troyanos, gusanos, bombas lógicas, etcétera. Cabe destacar la rapidez de propagación de estos programas dañinos a través del correo electrónico, las conexiones mediante redes de ordenadores y los nuevos servicios de intercambio de ficheros (P2P) o de mensajería instantánea. Hasta ahora algunos técnicos y administradores de redes se centraban en otros problemas de mayor nivel de complejidad, como los ataques contra servidores por parte de crackers o el análisis de agujeros de seguridad, relegando la protección

contra los virus y códigos dañinos a un segundo plano, ya que se consideraba como una tarea que realizan de forma automática los programas antivirus. Sin embargo, las nuevas formas de propagación de estos códigos dañinos y los graves problemas que ocasionan a las empresas y a los usuarios obligan a replantearse esta estrategia, prestando una mayor atención a la contención y erradicación de este tipo de ataques e incidentes de seguridad informática. Ataques de “Cross-Site Scripting” (XSS). Los ataques de “Cross-Site Scripting” consisten básicamente en la ejecución de código “Script” (como Visual Basic Script o Java Script) arbitrario en un navegador, en el contexto de seguridad de la conexión a un determinado servidor Web. Son ataques dirigidos, por lo tanto, contra los usuarios y no contra el servidor Web. Mediante “Cross-Site Scripting”, un atacante pueda realizar operaciones o acceder a información en un servidor Web en nombre del usuario afectado, suplantando su identidad. Estos ataques se pueden producir cuando el servidor Web no filtra correctamente las peticiones HTTP de los usuarios, los cuales pueden enviar cadenas de texto a través de formularios o directamente a través de la propia dirección URL de la página Web. Estas cadenas de texto podrían incluir código en lenguaje “Script”, que a su vez podría ser reenviado al usuario dentro de una página Web dinámica generada por el servidor como respuesta a una determinada petición, con la intención de que este código “Script” se ejecutase en el navegador del usuario, no afectando por lo tanto al servidor Web, pero sí a algunos de los usuarios que confían en él. Entre las posibilidades de ataque a través de “Cross-Site Scripting” podríamos destacar las siguientes:

Obtención de “cookies” e identificadores de usuarios, que permiten capturar sesiones y suplantar la identidad de los afectados.

Modificación de contenidos para engañar al visitante víctima del ataque “Cross-Site Scripting”, con la posibilidad de construir formularios para robar datos sensibles, como contraseñas, datos bancarios, etcétera.

Ataques de Inyección de Código SQL. SQL, “Structured Query Language” (Lenguaje de Consulta Estructurado), es un lenguaje textual utilizado para interactuar con bases de datos relacionales. La unidad típica de ejecución de SQL es la consulta (“query”), conjunto de instrucciones que permiten modificar la estructura de la base de datos (mediante instrucciones del tipo “Data Definition Language”, DDL) o manipular el contenido de la base de datos (mediante instrucciones del tipo “Data Manipulation Language”, MDL). En los servidores Web se utiliza este lenguaje para acceder a bases de datos y ofrecer páginas dinámicas o nuevas funcionalidades a sus usuarios. El ataque por inyección de código SQL se produce cuando no se filtra de forma adecuada la información enviada por el usuario. Un usuario malicioso podría incluir y ejecutar textos que representen nuevas sentencias SQL que el servidor no debería aceptar. Este tipo de ataque es independiente del sistema de bases de datos subyacente, ya que depende únicamente de una inadecuada validación de los datos de entrada. Como consecuencia de estos ataques y, dependiendo de los privilegios del usuario de base de datos bajo el cual se ejecutan las consultas, se podría acceder no sólo a las tablas relacionadas con la operación de la aplicación del servidor Web, sino también a las tablas de otras bases de datos alojadas en el mismo servidor Web. También pueden propiciar la ejecución de comandos arbitrarios del sistema operativo del equipo del servidor Web. Ataques contra los sistemas criptográficos. Los ataques contra la seguridad de los sistemas criptográficos persiguen descubrir las claves utilizadas para cifrar unos determinados mensajes o documentos almacenados en un sistema, o bien obtener determinada información sobre el algoritmo criptográfico utilizado. Podemos distinguir varios tipos de ataques contra los sistemas criptográficos:

Los “ataques de fuerza bruta”, que tratan de explorar todo el espacio posible de claves para romper un sistema criptográfico.

Los “ataques de diccionario”, que trabajan con una lista de posibles contraseñas: palabras de un diccionario en uno o varios idiomas, nombres comunes, nombres de localidades o accidentes geográficos, códigos postales, fechas del calendario, etcétera.

Los ataques contra el diseño del algoritmo.

Los ataques contra los dispositivos hardware o software que lo implementan.

Las distintas técnicas de criptoanálisis: criptoanálisis lineal, diferencial, técnicas de análisis estadístico de frecuencias, etcétera. Fraudes, engaños y extorsiones. Los fraudes y estafas financieros a través de Internet se han hecho muy frecuentes en estos últimos años. Se utiliza el término de “phishing” para referirse al tipo de ataques que tratan de obtener los números de cuenta y las claves de acceso a servicios bancarios, para realizar con ellos operaciones fraudulentas que perjudiquen a los legítimos propietarios. Generalmente, se utilizan páginas Web falsas que imitan a las originales de los servicios bancarios que pretenden suplantar. El “pharming” es una variante del “phishing” en la que los atacantes utilizan un virus que conecta a las víctimas desde su ordenador a páginas falsas en lugar de a las legítimas correspondientes a sus propias entidades financieras, para sustraer sus datos (números de cuenta y claves de acceso). El “pharming” y el “phishing” también pueden ser empleados para robar y utilizar de forma fraudulenta números de tarjetas de crédito. Estos datos podrían ser utilizados para realizar ataques del tipo “salami”, consistentes en la repetición de gran cantidad de pequeñas operaciones, como transferencias bancarias de importe reducido, que podrían pasar inadvertidas a nivel individual, pero que en conjunto ocasionan un importante daño económico. Por otra parte, se han desarrollado virus y otros programas dañinos para facilitar las extorsiones y estafas a usuarios de Internet. Es lo que se conoce como “ransom-ware”, software malicioso cuyo fin es el lucro de su creador por medio de rescates. Así, podríamos mencionar casos como el del troyano PGPCoder, de mayo de 2005, que cifraba determinados archivos en el sistema infectado, dejando a continuación un mensaje solicitando dinero a los usuarios perjudicados si querían volver a restaurar sus ficheros (mediante el envío de una clave para descifrarlos). También podemos considerar dentro de este tipo de ataques la difusión de correos electrónicos con ofertas falsas o engañosas, así como la publicación de falsas noticias en foros y grupos de noticias, con distintas intenciones, como podría el caso de intentar alterar el valor de las acciones de una empresa (de hecho, ya se han producido varias de estas actuaciones en Estados Unidos y en Europa).

De hecho, los casos de chantaje y extorsión on-line se están extendiendo en países como Estados Unidos, a tenor de los últimos estudios publicados. En muchos de estos casos, los chantajistas aseguran tener información confidencial sobre la empresa y amenazan con difundirla si no reciben una determinada cantidad de dinero. Se ha podido comprobar que un porcentaje elevado de estas amenazas eran realizadas por un antiguo empleado de la propia empresa con acceso a datos internos o, incluso, alguien de la competencia. También han aumentado los casos de extorsión a particulares a través de Internet, consistentes en la publicación o amenaza de publicación de alguna información difamatoria sobre la víctima, utilizando algún medio de la Red (páginas Web, foros, grupos de noticias). En marzo de 2006 se anunciaba la propagación de un nuevo tipo de virus a través de Internet, capaz de bloquear el equipo informático de sus víctimas, solicitando un “rescate” de 300 dólares para revelar la clave para liberar el equipo en cuestión. Denegación del Servicio (Ataques DoS – Denial of Service). Los ataques de Denegación de Servicio (DoS) consisten en distintas actuaciones que persiguen colapsar determinados equipos o redes informáticos, para impedir que puedan ofrecer sus servicios a sus clientes y usuarios. Para ello, existen varias posibilidades de conseguirlo:

Ejecutar algunas actividades que produzcan un elevado consumo de los recursos de las máquinas afectadas: procesador, memoria y/o disco duro, provocando una caída en su rendimiento. Entre ellas podríamos citar el establecimiento de múltiples conexiones simultáneas, el envío masivo de ficheros de gran tamaño o los ataques lanzados contra los puertos de configuración de los routers.

Provocar el colapso de redes de ordenadores mediante la generación de grandes cantidades de tráfico, generalmente desde múltiples equipos.

Transmisión de paquetes de datos malformados o que incumplan las reglas de un protocolo, para provocar la caída de un equipo que no se encuentre preparado para recibir este tipo de tráfico malintencionado.

Sabotajes mediante routers “maliciosos”, que se encarguen de proporcionar información falsa sobre tablas de enrutamiento que impidan el acceso a ciertas máquinas de la red.

Activación de programas “bacteria”, cuyo objetivo es replicarse dentro de un sistema informático, consumiendo la memoria y la capacidad del procesador hasta detener por completo al equipo infectado.

Envío masivo de miles mensajes de correo electrónico (“mail bombing”), provocando la sobrecarga del servidor de correo y/o de las redes afectadas.

“Ataque reflector” (“reflector attack”), que persigue generar un intercambio ininterrumpido de tráfico entre dos o más equipos para disminuir su rendimiento o incluso conseguir su completo bloqueo dentro de una red informática.

Incumplimiento de las reglas de un protocolo. Para ello, se suelen utilizar protocolos no orientados a conexión, como UDP o ICMP, o bien el protocolo TCP sin llegar a establecer una conexión completa con el equipo atacado.

En relación con esta última posibilidad, el incumplimiento de las reglas de un protocolo, podemos enumerar varios tipos de ataques que han ocasionado numerosos problemas a distintos tipos de sistemas informáticos en los últimos años:

“El ping de la muerte”: mediante el comando “ping –l 65510 direccion_ equipo_victima”, que envía un paquete IP de un tamaño superior a los 65.536 bytes, provocando el reinicio o “cuelgue” del equipo víctima que lo recibe (si no ha sido protegido frente a esta eventualidad).

“Land Attack”: debido a un error en la implementación del protocolo TCP/IP en algunos sistemas Windows, se consigue “colgar” un equipo vulnerable mediante el envío de una serie de paquetes maliciosamente construidos, en los que la dirección y el puerto de origen son idénticos a la dirección y el puerto de destino.

“Supernuke” o “Winnuke”: ataque contra algunos sistemas Windows, que se quedan “colgados” o disminuyen drásticamente su rendimiento al recibir paquetes UDP manipulados (fragmentos de paquetes “Out-Of-Band”) dirigidos contra el puerto 137.

“Teardrop”: tipo de ataque consistente en el envío de paquetes TCP/IP fragmentados de forma incorrecta. Los equipos vulnerables que no hayan sido conveniente parcheados se “cuelgan” al recibir este tipo de paquetes maliciosos.

“SYN Flood”: este ataque se basa en un incumplimiento de las reglas básicas del protocolo TCP por parte del cliente. Al establecer la conexión mediante el procedimiento “three-way handshake”, se envía una petición de conexión al equipo víctima, pero no se responde a la aceptación de la conexión por parte de este equipo (generalmente se facilita una dirección IP falsa). El equipo víctima deja la conexión en estado de “semi-abierta”, consumiendo de este modo recursos de la máquina. Las conexiones “semi-abiertas” caducan al cabo de un cierto tiempo, liberando sus recursos. No obstante, si se envían muchas peticiones de conexión siguiendo el ataque de SYN Flood, se colapsarán los recursos del equipo víctima, que no podrá atender nuevas conexiones legítimas.

Hay que tener en cuenta que en los ataques de Denegación del Servicio (DoS) el atacante suele ocultar su verdadera dirección mediante técnicas de “IP Spoofing”. Además, en numerosas ocasiones se han empleado este tipo de ataques para encubrir otros ataques simultáneos que pretendían comprometer un sistema o red informático. Ataques de Denegación de Servicio Distribuidos (DDoS). Los Ataques de Denegación de Servicio Distribuidos (DDoS) se llevan a cabo mediante equipos “zombis”. Los equipos “zombis” son equipos infectados por virus o troyanos, sin que sus propietarios lo hayan advertido, que abren puertas traseras y facilitan su control remoto por parte de usuarios remotos. Estos usuarios maliciosos suelen organizar ataques coordinados en los que pueden intervenir centenares o incluso miles de estos equipos, sin que sus propietarios y usuarios legítimos lleguen a ser conscientes del problema, para tratar de colapsar las redes y los servidores objeto del ataque. Generalmente los equipos “zombis” cuentan con una conexión ADSL u otro tipo de conexión de banda ancha, de tal modo que suelen estar disponibles las 24 horas. Para luchar de forma eficaz contra este tipo de ataques es necesario contar con la colaboración de los proveedores de acceso a Internet, para filtrar o limitar el tráfico procedente de los equipos que participan en el ataque. En este sentido, cabría destacar una iniciativa pionera llevada a cabo a finales de mayo de 2005 por la FTC (Comisión Federal de Comercio estadounidense) para tratar de identificar y poner en “cuarentena” a los clientes de los proveedores de acceso a Internet cuyos ordenadores se hayan convertido (seguramente sin su conocimiento) en una máquina “zombi”. Los equipos “zombis” también están siendo utilizados por los “spammers” para la difusión masiva de sus mensajes de correo no solicitados.

El reto es asignar estratégicamente los recursos para cada equipo de seguridad y bienes que intervengan, basándose en el impacto potencial para el negocio, respecto a los diversos incidentes que se deben resolver. Para determinar el establecimiento de prioridades, el sistema de gestión de incidentes necesita saber el valor de los sistemas de información que pueden ser potencialmente afectados por incidentes de seguridad. Esto puede implicar que alguien dentro de la organización asigne un valor monetario a cada equipo y un archivo en la red o asignar un valor relativo a cada sistema y la información sobre ella. Dentro de los Valores para el sistema se pueden distinguir: Confidencialidad de la información, la Integridad (aplicaciones e información) y finalmente la Disponibilidad del sistema. Cada uno de estos valores es un sistema independiente del negocio, supongamos el siguiente ejemplo, un servidor Web público pueden poseer los requisitos de confidencialidad de baja (ya que toda la información es pública), pero de alta disponibilidad y los requisitos de integridad. En contraste, un sistema de planificación de recursos empresariales (ERP), sistema puede poseer alto puntaje en los tres variables. Los incidentes individuales pueden variar ampliamente en términos de alcance e importancia.

UNIDAD DIDÁCTICA 3. CRITERIOS PARA LA DETERMINACIÓN DE LAS EVIDENCIAS OBJETIVAS EN LAS QE SE SOPORTARÁ LA GESTIÓN DEL INCIDENTE. El cómputo forense opera diversas herramientas informáticas para determinar el estado de un sistema luego de que sus medidas de seguridad han sido sobrepasadas y vulneradas, con la finalidad de encontrar evidencias que permitan definir, con toda certeza, los mecanismos que los intrusos utilizaron para acceder a ella, así como de desarrollar las mejoras y/o técnicas que deben seguirse para evitar futuras incursiones ajenas en el sistema. Por ello, podemos determinar que el principal criterio a la hora de recoger evidencias será asegurarnos de que estas nos permitan definir los mecanismos que los intrusos han utilizado para entrar en el sistema. Las herramientas que utilizan los peritos forenses en materia de cómputo para dar con los intrusos, y saber a ciencia cierta qué hicieron en el sistema, se han desarrollado al paso del tiempo, para que nos ayuden en cuestiones de velocidad y faciliten identificar lo que realmente le pasó al sistema y qué es lo que le puede suceder, en su contra parte igualmente se han desarrollado herramientas bastantes sofisticadas en contra de los análisis forenses (herramientas y técnicas que intentan no dejar rastros, camuflarlos o borrarlos, de tal manera que se dificulte una posterior investigación). Generalmente, la detección de ataques trabajará con la premisa de que nos encontramos en la peor de las situaciones, suponiendo que el atacante ha obtenido un acceso al sistema y que es capaz de utilizar o modificar sus recursos. Criterios para la recolección de evidencias.

El primer criterio, conocido como sensores basados en equipo (Host based sensors), se encarga de analizar y recoger información de eventos a nivel de sistema operativo (como por ejemplo, intentos de conexión y llamadas al sistema).

En el segundo criterio encontramos sensores que recogen información de eventos sucedidos a nivel de tráfico de red (por ejemplo, analizando las cabeceras IP de todos los datagramas que pasan por la interfaz de red). Este tipo de componentes se conoce como sensores basados en red (Network based sensors).

El tercer criterio, conocido como sensores basados en aplicación (Application based sensors), recibe la información de aplicaciones que se

están ejecutando, y podrían ser considerados como un caso especial de los sensores basados en equipo.

Elección de criterio. Durante los últimos años se ha debatido bastante cuál de los tres criterios de sensores ofrece mejores prestaciones. Actualmente, la mayoría de los sistemas de detección tratan de unificar las tres opciones, ofreciendo una solución de criterios híbrida. Criterios basados en equipo y en aplicación. Los criterios basados en equipo y en aplicación podrán recoger información de calidad, además de ser fácilmente configurables y de poder ofrecer información de gran precisión. Además, estos datos pueden llegar a tener una gran densidad de información como, por ejemplo, la información reportada por los servidores de ficheros de registro del sistema. También pueden llegar a incluir gran cantidad de información de pre-procesado, que facilitará el trabajo de los componentes de análisis de la información. Por contra, estos criterios pueden repercutir notablemente en la eficiencia del sistema en el que se ejecuten. Criterios basados en red. La principal ventaja de los criterios basados en red, frente a las otras dos soluciones, es la posibilidad de trabajar de forma no intrusiva. Por lo tanto, la recogida de información no afecta a la forma de trabajar de los equipos o a la propia infraestructura. Al no residir forzosamente en los equipos que hay que analizar, son más resistentes a sufrir ataques. Por otra parte, la mayoría de los sensores basados en red son independientes del sistema operativo y pueden obtener información a nivel de red (como, por ejemplo, la existencia de fragmentación en datagramas IP) que no podría ser proporcionada por criterios basados en equipo.

UNIDAD DIDÁCTICA 4. ESTABLECIMIENTO DEL PROCESO DE DETECCIÓN Y REGISTRO DE INCIDENTES DERIVADOS DE INTENTOS DE INTRUSIÓN O INFECCIONES. Proceso de detección. El proceso que lleva a cabo un Sistema Detector de Intrusos (IDS) para detectar las intrusiones en un sistema consta de 4 fases como se puede ver en la en la siguiente figura:

A continuación explicamos cada una de estas fases: Prevención. Lo primero que debe hacer un IDS es evitar los ataques. Para ello deberá disponer de mecanismos que dificulten las intrusiones. El sistema realizará una simulación con el tráfico que está pasando por la red o por el dispositivo y determinará si se puede llegar a una situación sospechosa, en cuyo caso se pasará a la siguiente fase del proceso. Monitorización de la intrusión. Cuando el sistema detecte actividad sospechosa monitorizará el tráfico para que pueda ser analizado. También puede guardar un registro del tráfico sospechoso para que pueda ser revisado por el administrador del sistema más tarde. Una vez analizado el tráfico monitorizado pasamos a la siguiente fase.

Detección de la intrusión. Después de analizar el tráfico, el sistema determina si la actividad sospechosa es una intrusión al sistema por medio de las diferentes técnicas. Una vez detectado el ataque los IDS deberán notificarlo. Y así pasamos a la última fase del proceso. Respuesta. Por lo general los IDS no actúan para detener la amenaza o eliminarla sino que se limitan a informar al sistema o a su administrador. Asimismo crean archivos de log (de registro) para poder realizar el análisis forense que permite identificar al atacante y mejorar la seguridad del sistema. Otra forma de explicar el proceso seguido por un IDS para la detección de intrusiones es ver el funcionamiento del sistema dentro de la arquitectura, es decir, el camino que siguen los datos desde que son recogidos hasta que se determina si pueden formar parte de un ataque. En él se distinguen tres zonas de funcionamiento principales, que se detallan a continuación:

En primer lugar, se recogen los datos siguiendo una política determinada. Esta política se refiere a la fuente y el momento en el que se recogen los datos. Estos datos pasan al generador de eventos que creará distintos conjuntos de eventos dependiendo del tipo de datos recogidos (syslogs, paquetes de la red o información del sistema).

Estos conjuntos de eventos se usan en el módulo de detección para determinar si puede existir un ataque al sistema. El sensor usa la información proporcionada por el sistema y una política determinada de detección para clasificar los datos proporcionados como ataques o como tráfico normal.

Por último, los datos generados por el módulo de detección pasan al módulo de respuesta que seguirá una política definida para responder a los ataques detectados.

Registro de incidentes. Usar y examinar los registros de sucesos. Los registros de sucesos son la herramienta principal de supervisión para realizar el seguimiento de la actividad de intrusión en un sistema en particular o contra él. Los administradores de red deberían examinarlos en busca de sucesos

inesperados e investigar cualquier actividad sospechosa. Los registros de sucesos se pueden examinar de forma manual o mediante una herramienta de cotejo de registros de sucesos. Registros de sucesos Los sistemas comparten tres registros de sucesos comunes: de aplicación, de seguridad y del sistema. Tanto los administradores como los usuarios pueden tener acceso a la utilidad Visor de sucesos, en el menú Herramientas administrativas; los sistemas tienen un complemento Visor de sucesos predeterminado. Otros registros, como los del Servidor DNS, el Servicio de replicación de archivos y el Servicio de directorio, pueden estar disponibles en función de la plataforma de Windows y de cuándo se haya instalado. Cualquier registro puede proporcionar una evidencia de una intrusión en la seguridad. Automatizar la visualización de sucesos en varios equipos. Si tiene que supervisar más de un sistema, ir a cada equipo personalmente puede ser una tarea difícil desde un punto de vista administrativo. La utilidad Visor de sucesos le permitirá abrir los registros de sucesos de equipos remotos, si usted dispone de derechos administrativos. Microsoft proporciona otras dos herramientas para ver y administrar varios equipos a la vez. EventCombMT es una utilidad gratuita de Microsoft que se utiliza para buscar en registros de sucesos remotos a través de dominios diferentes. El uso de una consola de Microsoft Operations Manager (MOM) basada en el Web ofrece un completo conjunto de características destinadas a ayudar a los administradores a supervisar y administrar los sucesos y el rendimiento de servidores basados en Windows. Se pueden crear reglas y directivas predeterminadas para administrar servidores y responder a los sucesos de los servidores que intenten infringirlas.

UNIDAD DIDÁCTICA 5. GUÍA PARA LA CLASIFICACIÓN Y ANÁLISIS INICIAL DE INTENTO DE INTRUSIÓN O INFECCIÓN, CONTEMPLANDO EL IMPACTO PREVISIBLE DEL MISMO. Existen diferentes barreras que los sistemas tienen para impedir accesos no autorizados a ellos. Esto es debido a qué es fundamental detectar una intrusión lo antes posible, y que así, ésta cause el menor daño en el sistema. Podemos definir “intrusión” como cualquier conjunto de acciones que intentan comprometer la integridad, confidencialidad o disponibilidad de una información o un recurso. Normalmente una intrusión intenta:

- Acceder a una determinada información. - Manipular cierta información. - Hacer que el sistema no funcione de forma segura o inutilizarlo.

Una intrusión es, por tanto, la violación de la política de seguridad del sistema. Los intrusos pueden utilizar fallos en la arquitectura de los sistemas y el conocimiento interno del sistema operativo para superar el proceso normal de autentificación. Clasificación de intrusiones. Si se tiene en cuenta la naturaleza de la intrusión se puede hacer una primera clasificación o categorización de la siguiente manera:

Intrusiones de uso erróneo. Se definen como ataques bien definidos contra puntos débiles sabidos de un sistema. Este tipo de intrusiones pueden ser detectadas observando ciertas acciones que son llevadas a cabo sobre ciertos objetos de dicho sistema.

Intrusiones de anomalía. Se podrían definir como desviaciones de los patrones normales de uso del sistema. Pueden ser detectadas guardando y revisando periódicamente un perfil del sistema, en el cual se detectan desviaciones o alteraciones significativas.

Independientemente de si la intrusión está clasificada como una intrusión anómala o como de uso erróneo, existen diferentes maneras primarias en que los intrusos pueden acceder a un sistema informático, en base a las cuales se puede establecer una segunda clasificación para intrusiones:

Intrusión física: En este caso el intruso tiene acceso físico a la máquina (puede utilizar el teclado, etc...).

Intrusión del sistema. El intruso tiene una cuenta de usuario en el sistema con pocos privilegios pero puede llevar a cabo estrategias para que le sean asignados privilegios administrativos adicionales.

Intrusión alejada. Tentativa de penetrar un sistema remotamente, a través de la red.

Tipos de intrusos. Los intrusos son usuarios no autorizados en un sistema. Si queremos diferenciar tipos de intrusos, una posible clasificación sería la siguiente:

Externos. Este tipo de usuarios no está autorizado para usar ningún recurso del sistema. Comúnmente son denominados intrusos (aunque intrusos lo son todos) y son el objetivo central de la seguridad física y de las técnicas de cortafuegos, por ejemplo.

Interno. A diferencia de los usuarios externos, este tipo de usuarios están

autorizados para usar solamente algunos de los recursos del sistema. A su vez, podemos dividirlos en:

- “Enmascarados”: Imitan o se hacen pasar por otros usuarios.

- Clandestinos: Evaden todo tipo de control y constituyen, sobre todo,

una amenaza para sistemas débiles y sistemas mal manejados.

Uso malicioso. Este tipo de usuarios incluye a aquellos que emplean mal los privilegios que tienen asignados. Todo usuario de un sistema constituye una amenaza potencial para el mismo, independientemente de su origen o de la forma en que se hayan autentificado.

Clasificación basa en el efecto de las intrusiones. A continuación se detallan los diferentes tipos de intrusiones que pueden afectar a un determinado sistema, basándose en los efectos que causan y en la manera de ejecutarse. Intentos de entrada. Ocurre, cuando una persona ajena a nuestro sistema intenta acceder de forma no autorizada al mismo. Se detectan normalmente por modelos de comportamiento atípicos, o violaciones de las restricciones dadas por la política de seguridad. Ataque enmascarado. Cuando a partir de un usuario del sistema se intenta un ataque al mismo. Éste es detectado a partir de modelos de comportamiento atípico o violaciones de contraseñas de seguridad. Penetraciones en el sistema de control. Son normalmente detectadas a partir de la observación de modelos especiales de actividad. Fuga. Cuando se utilizan de manera excesiva los recursos de un sistema. Se detectan normalmente por usos anormales de dichos recursos. Rechazo de servicio. Detectados por un uso atípico de los recursos del sistema. Uso malicioso. Detectado normalmente por modelos de comportamiento atípico, violaciones de las restricciones de seguridad, o uso de privilegios especiales.

UNIDAD DIDÁCTICA 6. ESTABLECIMIENTO DEL NIVEL DE INTERVENCIÓN REQUERIDO EN FUNCIÓN DEL IMPACTO PREVISIBLE. Unidades de respuesta. Las unidades de respuesta de un sistema de detección se encargaran de iniciar acciones de respuesta en el momento en que se detecte un ataque o intrusión. Estas acciones de respuesta pueden ser automáticas (respuesta activa) o requerir interacción humana (respuesta pasiva). Las respuestas activas tienen como objetivo actuar contra el ataque, intentando su neutralización, en el momento en el que es detectado (o mientras una intrusión todavía continúa en curso). Un ejemplo de respuesta activa puede ser la cancelación de la conexión en red que originó el ataque o el propio seguimiento del ataque que permitiría más adelante el análisis correspondiente. Por contra, las respuestas pasivas se limitan a lanzar una alarma para informar y describir el ataque detectado en el administrador del sistema. La mayoría de los componentes de respuesta pasiva ofrecen distintas formas de hacer llegar esta información al administrador como, por ejemplo, mediante un correo electrónico, mediante la utilización de mensajes SMS, etc. El problema de las respuestas activas es que pueden acabar en una denegación de servicio contra usuarios o sistemas legítimos. Es muy probable que algunas de las alarmas que los procesadores hacen saltar sean incorrectas. Por ejemplo, si la unidad de respuesta cortara inmediatamente con la conexión que originó esta alarma, o con aquellos procesos considerados sospechosos, ello podría suponer la pérdida de trabajo de un usuario o servicio inocente. En la mayoría de los sistemas (por ejemplo, servidores de comercio electrónico) este tipo de errores puede suponer la pérdida de clientes, la cual cosa es inadmisible. Por este motivo, la mayoría de empresas del sector del comercio electrónico se decantan por la contratación de especialistas que, manualmente, analicen los informes generados por el sistema de detección para determinar si es necesaria una respuesta activa ante tal aviso. Al igual que los criterios para la determinación de evidencias, las unidades de respuesta se podrían clasificarse en distintas categorías según el impacto previsible de la intrusión informática.

Las dos categorías más generales son las unidades de respuesta basadas en equipo y las unidades de respuesta basadas en red.

1. Unidades de respuesta basadas en equipo. Se encargan de actuar a nivel de sistema operativo, como, por ejemplo, bloqueo de cuentas de usuarios, finalización de la ejecución de procesos, realizar un cambio de permisos, etc.

2. Unidades de respuesta basadas en red. Actúan a nivel de red cortando

intentos de conexión, filtrando direcciones sospechosas, cerrando puertos TCP/UDP, etc.

El nivel de intervención en los sistemas o en la red dependerá del tipo de intrusión y de la gravedad y profundidad de la misma. El sistema de detección de intrusos IDS, valorará el alcance de esta intrusión y de los daños que pueda ocasionar, gestionando automáticamente un plan de acción contra la intrusión basado en las unidades de respuesta, jerarquizadas en diferentes niveles de acuerdo al impacto previsible de la incidencia informática.

UNIDAD DIDÁCTICA 7. GUÍA PARA LA INVESTIGACIÓN Y DIAGNÓSTICO DEL INCIDENTE. Ante la sospecha de que el sistema haya sido objeto de un ataque, se ha de determinar lo siguiente:

Si realmente el sistema ha sido atacado.

Si el ataque ha tenido éxito.

En qué grado se ha comprometido el sistema en caso de que haya sido atacado.

La tarea de detectar posibles intrusos será más o menos fácil en función del sistema operativo del que se disponga, puesto que algunos sistemas operativos modernos son complejos y poseen numerosos “sitios” en los cuales los intrusos pueden ocultar sus actividades. La mayor parte de los intrusos dejan señales de sus actividades en el sistema. En principio, estando al día en materia de seguridad, así como de fallos que van surgiendo, no habrá problemas de que un intruso entre en el sistema. Pero en muchas ocasiones el peligro viene de los propios usuarios internos del sistema, los cuales presentan un gran riesgo debido a que ya tienen acceso al sistema, aunque también existe métodos de seguridad para controlar a los usuarios legítimos. Lo fundamental es descubrir si realmente ha entrado un intruso, ya que en muchas ocasiones pensamos que ha entrado alguien pero no es cierto. A continuación se detallan las pautas a seguir para investigar y diagnostica si actualmente hay un intruso en el sistema, o si ya ha ocurrido la intrusión. Investigar y diagnosticar un intruso actualmente en el sistema. Cuando se sospecha que un intruso puede que encuéntrese actualmente en el sistema se deben seguir los siguientes pasos:

Comprobar si los usuarios que se encuentran actualmente en el sistema son sospechosos.

Comprobar qué procesos se están ejecutando y quién los ejecuta. Las sospechas de que un intruso se encuentra en el sistema pueden venir fundamentadas porque en el intento de comprobar si dicho intruso ha atacado el sistema nos damos cuenta que existe una gran posibilidad que se encuentre en él en ese mismo instante, por ejemplo en las fechas de los log’s o en las fechas de procesos (o ficheros).

Los pasos fundamentales a seguir son: Visualización de los usuarios “logged” en el sistema. Cuando se sospecha que hay intrusos en el sistema, lo primero a determinar es dónde están y qué están haciendo. Existen diversos comandos que permiten conocer los usuarios que están actualmente en el sistema, por ejemplo en Linux se encuentran los siguientes:

Comando “w”: este comando muestra una visión general de todos los usuarios que se encuentran en el sistema así como los programas que están ejecutando. Prestando especial atención a los siguientes aspectos:

- Validar si todos los usuarios son válidos. - Validar que no llevan conectados en el sistema una cantidad de

tiempo excesiva. - Asegurar que los usuarios no estén ejecutando programas que

puedan resultar sospechosos. ·

Comando “finger”: es similar al anterior y muestra los usuarios que están en el sistema, el terminal en el que se encuentran y el tiempo que llevan conectados. Además, muestra también desde dónde se han conectado éstos. También se puede hacer un “finger” que indique quién está conectado en un ordenador remoto. Una vez visto el resultado de la ejecución de “finger” se ha de determinar:

1. Que todos los usuarios son válidos. 2. Que los usuarios no están conectados en el sistema una cantidad

de tiempo excesiva. 3. Y determinar que los usuarios se han conectado desde una

localización válida.

Comando “who”: muestra información almacenada en el fichero/etc/utmp. Su salida es muy similar a la de “finger” y por lo tanto se han de verificar los mismos puntos expuestos para dicho comando.

Los comandos anteriores pueden ser modificados por los intrusos de manera que quede oculta su presencia en el sistema. Por lo que hay que estar seguros que los comandos no han sido sustituidos por troyanos con el mismo nombre.

Visualización de los procesos activos. Un intruso puede dejar una tarea ejecutándose en el sistema sin haber estado un tiempo excesivo en el mismo, de modo que puede haber pasado desapercibido por alguien que haya querido detectar intrusos mediante los comandos citados en el apartado anterior. Incluso el intruso podría estar en este mismo instante ejecutando procesos del sistema. Para descubrir procesos que puedan realizar tareas que atenten contra el sistema se pueden emplear los siguientes comandos:

Comando “ps”: muestra los procesos que actualmente se están ejecutando en el sistema. Una vez ejecutado el comando y visualizada su salida, es importante fijarse en los siguientes aspectos:

1. Hay que prestarle especial atención a los procesos que se

ejecutan durante un período largo de tiempo. 2. También suelen ser sospechosos los procesos que comienzan a

ejecutarse a horas inusuales (por ejemplo, de madrugada). 3. No se debe desconfiar de los procesos con nombres que pueden

resultar extraños. 4. Procesos que consumen un porcentaje elevado de CPU. 5. Procesos que no se ejecutan desde un terminal.

Puede darse el caso de que un sistema contenga una versión modificada del comando, para que no se visualicen procesos intrusos. También puede darse que un proceso intruso se esté ejecutando bajo el nombre de un proceso válido; en este caso resultaría difícil identificarlo como proceso sospechoso. Como ejemplo, decir que algunos intrusos, a menudo, ejecutan programas sniffers bajo nombres tan comunes como puede ser “sendmail” o “inetd”.

Comando “crash”: visualiza una lista de todos los procesos que se están ejecutando en un momento dado en el sistema, aunque la ejecución de “crash” puede considerarse como una forma de chequear contra el comando “ps”, de manera que se puede comprobar si algún proceso de los que se visualizan con “crash” no se visualiza con “ps”. Se debe centrar la atención en los siguientes aspectos, los cuales pueden indicar la presencia de actividad “extraña” en el sistema:

1. Una situación, que nos informaría rotundamente de que el

sistema está siendo atacado, es encontrarnos con procesos que no aparecen reflejados en la salida del comando “ps” (usando el PID para identificarlos).

2. Al igual que con “ps” hay que desconfiar de los procesos que consumen un porcentaje elevado de CPU.

3. También tener en cuenta los nombres de comandos inusuales (para lo que hay que fijarse en la columna NAME de la salida).

La salida de todos estos comandos, puede ser modificada a favor del intruso. Investigar y diagnosticar una intrusión ya ocurrida. Este apartado solo tratará el punto de vista de cuando un intruso ya ha invadido el sistema. La utilización de los comandos y consejos a los que se hace referencia a continuación, es aconsejable ante la sospecha de que un intruso haya estado en el sistema pero que ya lo ha abandonado. Ante dicha sospecha hay que buscar una serie de señales que permitan encontrar huellas de que el intruso haya dejado tras de sí en el sistema. Estas señales se pueden enumerar en una serie en:

1. Examinar los archivos log.

2. Buscar archivos setuid y setgid.

3. Chequear los archivos binarios del sistema.

4. Comprobar puertos abiertos.

5. Chequear si hay sniffers.

6. Examinar archivos que estén ejecutándose como 'cron' y 'at'.

7. Chequear si hay servicios no autorizados.

8. Examinar el archivo /etc/passwd.

9. Chequear la configuración del sistema y la red.

10. Buscar todos lados archivos escondidos o inusuales.

11. Examinar todas las máquinas en la red local. Examinar los archivos log. Lo primero que se debe hacer siempre que se tenga la sospecha de que el sistema ha sido atacado (y lo más importante) es examinar los archivos log a conexiones de lugares inusuales u otra actividad inusual. Por ejemplo, se debe buscar el último

acceso al sistema de un usuario, el conteo de procesos, todos los accesos generados por syslog y otros accesos de seguridad. Hay que tener en cuenta que esto no es infalible ya que muchos intrusos modifican los archivos log para esconder su actividad. A continuación se detallan los principales log’s que se deben revisar. xferlog Si el sistema comprometido tiene servicio FTP, este fichero contiene el loggeo de todos los procesos del FTP y su localización suele ser el directorio /var/adm/. Se puede examinar qué tipo de herramientas ha subido el intruso y qué ficheros ha bajado del servidor. Suele ser bastante interesante revisar este log ya que un intruso puede usar carpetas ocultas del directorio del FTP para guardar la información y aplicaciones que necesite para atacar el sistema. La información que almacena este log suele ser la siguiente:

La hora y la fecha a la que se transfiere.

Nombre del host remoto que inicia la transferencia.

Tamaño de fichero transferido.

Nombre del fichero transferido.

Modo en que el archivo fue transferido (ASCII o binary).

Flags especiales (por ejemplo C para comprimidos, U para descomprimidos, etc.)

Dirección de transferencia.

El tipo de usuario que entró en el servicio (apara un usuario anónimo, g para un invitado y r para un usuario local).

Secure. Algunos sistemas loggean mensajes al fichero secure, ya que utilizan algún software de seguridad para ello, como el TCP Wrapper. En todo momento una conexión establecida con uno de los servicios que se están ejecutando bajo Inetd y que usan TCPWrappers, un mensaje de logeo es añadido a al fichero “secure” que se suele encontrar en “/var/secure”. Cuando se examina el fichero log, se deben buscar anomalías tales como servicios a los que se accedió por un método no habitual y desde host desconocidos.

Wtmp. Guarda un log cada vez que un usuario se introduce en el equipo, sale de él o la máquina resetea. Dicho fichero se ubica normalmente en/etc/wtmp, /var/log/wtmp ó /var/adm/wtmp y contiene la información en formato usuario con la hora de conexión, IP origen del usuario, etc. por lo que se puede averiguar de donde provino el intruso. También puede obtenerse información del tiempo durante el cual el intruso ha estado en el sistema y el momento en el que lo ha abandonado. Una vez visualizada la salida de la ejecución, se debe:

Examinar las entradas registradas alrededor de la hora en la que se sospecha que el sistema pudo ser atacado, las que tienen un login que no resulta familiar, los logins de lugares inusuales, etc.

Examinar la posibilidad de que se perdiera el fichero/var/adm/wtmp o que fuera cambiado por uno con agujeros en su salida con la finalidad de ocultar la presencia del intruso.

Utmp. Guarda un registro de los usuarios que están utilizando el equipo mientras están conectados a él. Este fichero se encuentra en: /var/log/utmp, /var/adm/utmp o /etc/utmp. Lastlog. En él se encuentra el momento exacto en que entró el usuario en el equipo por última vez. En algunas versiones de Linux, por ejemplo, también se almacena el último acceso fallido en la cuenta de un usuario. Se ubica en /var/log/lastlog o en /var/adm/lastlog y su contenido suele ser visualizado cada vez que se entra en el sistema. acct o pacct. Registra todos los comandos ejecutados por cada usuario, pero no sus argumentos. Se encuentra en: /var/adm/acct ó /var/log/acct.

Borrar las huellas con el accounting activado es mucho más difícil para el intruso, aunque hay que tener en cuenta que lo que pueden hacer es reducir la información de su presencia en el sistema, empleando los siguientes métodos:

El primero es que, nada más entrar en el sistema, pueden copiar el fichero acct a otro fichero y, antes de abandonar el equipo, sólo tendrían que copiar dicho archivo de nuevo al acct. Así, todos los comandos ejecutados durante la sesión no aparecen en el fichero acct. Un administrador puede darse cuenta de esta situación porque su entrada queda registrada en el sistema, así como las dos copias.

El segundo método que podrían emplear sería hacerse con un editor para el fichero acct que borrara los datos correspondientes al usuario, dejando intactos los del resto. Pero otra vez el administrador puede darse cuenta si el intruso realizó esta operación, ya que la ejecución del programa editor que borra sus huellas quedaría registrado como comando por su usuario.

La última opción que puede emplear un hacker sería dejar el fichero acct con cero bytes lo cual llamaría la atención.

Syslog. Esto no es un log sino una aplicación que viene con el sistema operativo. Dicha aplicación genera mensajes que son enviados a determinados ficheros donde quedan registrados. Estos mensajes son generados cuando se dan unas determinadas condiciones relativas a seguridad, información, etc. Los mensajes de errores típicos están ubicados en /var/log/messages, /usr/adm/messages, /var/adm/messages o incluso /var/syslog. De esta información se puede obtener lo siguiente:

Información de dirección de E-mail que provengan de hosts sospechosos. Pues esto puede indicar que un intruso está enviando información a tu sistema desde otro remoto.

Conexiones vía Telnet, tanto de entrada como de salida, deberían ser examinadas.

Un pequeño archivo puede ser sospechoso si en el log se indica que el archivo ha sido editado o borrado. En muchos casos, los logs del syslog guardan información que puede ser sospechosa y realmente no los sea, lo cual resta mucho tiempo a la hora de examinar lo logs. Además estos logs suelen ser muy largos y examinarlos puede resultar complicado.

En este fichero se pueden encontrar actividades no deseadas, como las siguientes:

Una autorización de entrada en un directorio de root no autorizado.

Intento de entrar como root en el sistema (mediante “su”) o en una cuenta privilegiada.

Si un intruso intenta borrar las huellas que deja dicho daemon, necesita tener privilegios de root, por lo que los intrusos mirarán el fichero de configuración para saber en qué ficheros están guardando la información. Cuando lo averigüen, los visualizarán y buscarán algún mensaje de la intromisión en el equipo. Cuando los encuentran, los borran y cambian la fecha del fichero. Para evitar una modificación de los log’s se debe seguir alguno delos siguientes consejos:

Mandar la parte más sensible del registro a una impresora, deforma que al intruso le sería imposible borrar estas entradas. Aunque si se da cuenta del truco, puede colapsar la impresora mandándole imprimir basura.

Utilizar otro ordenador como registro, necesitará atacar esta otra máquina para eliminar todas sus huellas.

Mandar los logs por correo electrónico. Por culpa de que los logs no son definitivos en la detección de intrusos se recomienda seguir los pasos que vienen a continuación. Buscar archivos setuid y setgid. Los sistemas permiten a los usuarios elevar temporalmente sus privilegios a través de un mecanismo llamado setuid Cuando un archivo con el atributo setuid es ejecutado por un usuario, el programase va a ejecutar con los permisos del propietario del mismo. Por ejemplo, el programa “login” es un programa con el atributo setuid y propiedad del root. Cuando un usuario lo invoca se habilita el acceso al sistema con privilegios de “superusuario” en lugar de los del propio usuario. Los ficheros setuid aparecen en el listado de directorios con una “s” en lugar de una “x” en la posición correspondiente al bit de ejecución. Los intrusos frecuentemente dejan copias setuid para que así les sea autorizado el acceso como root en una ocasión posterior. Para la búsqueda de este tipo de

archivos, está disponible el comando find (el comando find puede ser sustituido por un troyano para esconder ficheros del intruso, por lo que no es totalmente fiable), aunque existen más comandos para buscar este tipo de archivos. Chequear los archivos binarios del sistema. En ocasiones, los intrusos modifican los programas del sistema para ocultar su intrusión. Es aconsejable revisar los archivos binarios del sistema para asegurarse de que no han sido modificados. Existen varias herramientas conocidas para modificar los archivos binarios, como RootKit que permite a un intruso cambiar los binarios del sistema por troyanos que son copias exactas de los originales. Los programas troyanos pueden producir el mismo checksum y timestamp estándar como la versión legítima. Debido a esto, el comando estándar “sum” y los timestamps asociados con los programas no son suficientes para determinar si han sido remplazados. Por ello, hay que usar otras herramientas complementarias, para detectar estos programas troyanos. Adicionalmente, se puede considerar usar una herramienta (PGP por ejemplo) para "firmar" la salida generada. Además también se puede comparar con las copias de seguridad aunque puede que estas copias también hayan sido sustituidas por un troyano. Por ejemplo, los binarios encontrados en localizaciones inusuales pueden ser comparados. Comprobar puertos abiertos. Un intruso que ha atacado el sistema puedo haber dejado puertos o conexiones abiertas de procesos. Para poder comprobar esto se puede usar el comando “netstat”, que principalmente da información de las conexiones abiertas. Lo que se debería hacer es comparar la salida de este comando con la de “last-n” para poder comprobar si existe relación entre los usuarios que se conectaron al sistema y las conexiones abiertas. Leyendo la salida de este comando se puede obtener información de:

Si se tiene una conexión telnet que no está relacionada con la salida de los comandos.

Conexiones a otras redes. En algunos casos, en los sistemas comprometidos se ha introducido una versión troyana que no enseña las conexiones hacia o desde el origen del intruso.

Chequear si hay sniffers. Es importante comprobar que en los sistemas no existe el uso no autorizado de un programa de monitoreo de red, comúnmente llamado como sniffer. Los intrusos pueden usar un sniffer para capturar información de la cuenta y password de un usuario. Los sniffers son la mayor fuente de ataques hoy en día. Muchos adaptadores ethernet están configurados (y deben estarlo) para aceptar solo mensajes que son pedidos por ellos mismos. Un atacante o un sniffer puede establecer el adaptador de red en “modo promiscuo” para escuchar todas las tramas de ethernet, de esta forma todos los paquetes de datos que llegan a la placa son aceptados (no sólo los destinados a esa PC). De esta manera se puede "espiar" las "conversaciones”, passwords, …Normalmente cuando la interfaz pasa a modo promiscuo, queda reflejado en el fichero de logs. Uno de los comandos que se puede usar para determinar si un sniffer fue instalado en nuestro sistema es “ifconfig” (existen otros como ifstatus o cpm). Dicho comando muestra la configuración actual del interfaz de red. El “modo promiscuo” se puede ver activado como el último parámetro de la descripción de flag’s. Como otros comandos, éste, también puede ser un troyano. Si realmente hay sospechas de que un sniffer ha sido instalado se debería instalar la herramienta Cpm y ejecutarla. Esta herramienta testeará la interfaz de red directamente y mostrará un informe de si está en “modo promiscuo”. Otras posibles medidas para detectar el sniffer son:

Controlar y detectar los logs que genera el sniffer.

Controlar las conexiones al exterior, por ejemplo, el envío sospechoso de e-mail a cuentas extrañas.

Utilizar la herramienta “lsof” (LiSt Open Files), de forma que se monitoricen los programas que acceden al dispositivo de red.

Por otra parte, en caso de que no se pueda acceder y consultar el estado de las interfaces de red, puesto que el sniffer no está en el ordenador sino que se encuentra en alguna otra máquina de la red. Lo que hay que hacer, es utilizar algún defecto en la implementación concreta del protocolo TCP/IP por algún programa/comando o averiguar de alguna forma si hay algún sniffer corriendo en la red. Por ejemplo, una de las posibles técnicas, consiste en enviar paquetes a una máquina inexistente y cuya dirección no está dada de alta en el servidor de nombres, de esta manera se puede saber si hay un sniffer en la red, si posteriormente se detecta cualquier intento de acceso a la máquina ficticia.

Examinar archivos que estén ejecutándose como cron y at. Otro paso a seguir es examinar todos los archivos que están siendo ejecutados por cron y at. Se sabe que los intrusos dejan puertas traseras en archivos corriendo como cron o como at. Estas técnicas pueden permitir a un intruso volver a entrar en el sistema aunque se haya echado. Además se debe verificar que todos los archivos o programas relacionados con tareas del cron y at, y las tareas que se archiven por si mismas sean nuestras y que no tienen permiso de escritura. Chequear si hay servicios no autorizados. Es interesante chequear si hay servicios no autorizados dados de alta en el sistema. Se debe inspeccionar /etc/inetd.conf por si se le ha añadido algún servicio sin nuestra autorización o cualquier tipo de cambio. En particular hay que buscar entradas que ejecuten un programa shell (por ejemplo /bin/sh o /bin/csh) y chequear todos los programas que estén especificados en él. Para verificar que son correctos y que no han sido remplazados por troyanos. Además se debe comprobar la legitimidad de los servicios que nosotros mismos hemos dado de alta en el archivo /etc/inetd.conf. Los intrusos pueden habilitar un servicio que pensemos que previamente lo habíamos deshabilitado, o remplazar el programa inetd con unprograma troyano. Examinar el archivo /etc/passwd. Otro de los pasos a seguir en la detección de intrusos es chequear el archivo /etc/passwd en el sistema y buscar posibles modificaciones que se pudieran realizar en el mismo. En particular se debe buscar:

La creación no autorizada de nuevas cuentas.

Cuentas sin password.

Cambios de UID (específicamente UID 0 que es el “root”) a cuentas existentes.

Una entrada como “+::”. Actualmente las contraseñas no se guardan en el fichero anterior sino en otro.

Chequear la configuración del sistema y la red. Otro paso es examinar las entradas no autorizadas en los archivos de configuración del sistema y de la red. En particular hay que buscar entradas con signo '+' y nombres de host no locales inapropiados del sistema. Los ficheros en los que se guarda, no deben tener atributo de escritura para todo el mundo. Más específicamente, el fichero .rhosts es empleado para permitir el acceso remoto a un sistema y en algunas ocasiones es usado por los intrusos como puertas traseras. Si el fichero fue modificado recientemente puede que se haya usado para sabotear el sistema. Inicialmente y periódicamente se debe verificar que el host remoto y el nombre de los usuarios en dichos ficheros son consistentes. Buscar todos lados archivos escondidos o inusuales. A menudo, la mejor manera de averiguar si el sistema ha sido o no comprometido es a través del chequeo de los archivos del mismo. Los intrusos suelen ocultar su presencia en un sistema usando archivos o directorios ocultos o inusuales, ya que pueden ser usados para esconder herramientas que le permitan romper la seguridad del sistema o incluso pueden contener el /etc/passwd del sistema o de otros sistemas a los cuales ha entrado el intruso. Muchos intrusos suelen crear directorios ocultos utilizando nombres como '...' (punto-punto-punto), '..' (punto-punto), etc. De nuevo el comando find puede ser usado para buscar archivos ocultos. También deben examinarse los directorios ftp los cuales pueden ser escritos por usuarios anónimos (que sean intrusos) que almacenen y cambien ficheros. Examinar todos los ordenadores de la red local. Se debe examinar cuidadosamente todos los ordenadores de la red local en busca de indicios de que ésta haya sido comprometida. También hay que revisar los sistemas informáticos que los usuarios comparten mediante el acceso del .rhost Lógicamente si nuestro ordenador ha sido atacado, probablemente los sistemas de la red también hayan sido atacados.

UNIDAD DIDÁCTICA 8. ESTABLECIMIENTO DEL PROCESO DE RESOLUCIÓN Y RECUPERACIÓN DE LOS SISTEMAS TRAS UN INCIDENTE DERIVADO DE UN INTENTO DE INTRUSIÓN O INFECCIÓN. El proceso de resolución y recuperación está compuesto por tres fases, las cuales se detallan a continuación. Contención. El primer paso es elegir una determinada estrategia de contención del incidente de seguridad. Una primera opción sería llevar a cabo una rápida actuación para evitar el incidente pueda tener mayores consecuencias para la organización: apagar todos los equipos afectados, desconexión de estos equipos de la red informática, desactivación de ciertos servicios, etc. Esta estrategia de contención es la más adecuada cuando se puedan ver afectados servicios críticos para la organización, se pueda poner en peligro determinada información confidencial, se estén aprovechando los recursos de la organización para lanzar ataques contra terceros o cuando las pérdidas económicas puedan ser considerables.

Una segunda alternativa sería 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 de este modo reunir las evidencias necesarias que permitan iniciar las correspondientes actuaciones legales contra los responsables del incidente. Por otra parte, en algunos tipos de ataque las medidas de contención adoptadas podrían desencadenar mayores daños en los sistemas informáticos comprometidos.

También hay que tener en cuenta que en los ataques de Denegación de Servicio (DoS) puede resultar necesario contar con la colaboración de las empresas proveedoras de acceso a Internet o de Administradores de las redes de otras organizaciones para contener el ataque o la intrusión. Erradicación. Por su parte, la erradicación es la etapa en la que se llevan a cabo todas las actividades necesarias para eliminar los agentes causantes del incidente y de las secuelas, entre las que podríamos citar posibles “puertas traseras” instalados en los equipos afectados, contenidos y material inadecuado que se haya introducido en los servidores, cuentas de usuario creadas por los intrusos o nuevos servicios activados en el incidente. También será conveniente llevar a cabo una revisión de otros sistemas que se pudieran ver comprometidos a través de las relaciones de confianza con el sistema afectado. Recuperación. Por último, la recuperación es fase 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 segura, la configuración adecuada de los servicios e instalación de los últimos parches y actualizaciones de seguridad, el cambio de contraseñas que puedan haber sido comprometidas, la desactivación de las cuentas que hayan sido utilizadas en el incidente, la revisión de las medidas de seguridad para prevenir incidentes similares y la prueba del sistema para comprobar su correcto funcionamiento.

UNIDAD DIDÁCTICA 9. PROCESO PARA LA COMUNICACIÓN DEL INCIDENTE A TERCEROS, SI PROCEDE. El Plan de Respuesta a Incidentes hace referencia a una guía de actuación clara y detallada de los procedimientos a acciones necesarias para la restauración rápida, eficiente y segura de la capacidad de procesamiento informático y de comunicación de la organización, así como para la recuperación de los datos dañados o destruidos. Por otro lado, el Plan de Respuesta a Incidentes tiene que contemplar cómo la organización debería comunicar a terceros la causa y las posibles consecuencias de un incidente de seguridad informática.

Así, dentro de este Plan deberán estar previstos los contactos con organismos de respuesta a incidentes de seguridad informática (como puede ser el CERT), con las fuerzas de seguridad (Policía o Guardia Civil), con las agencias de investigación y con los servicios jurídicos de la organización. Además, también puede ser necesario establecer contacto con proveedores de acceso a Internet, ya sea el proveedor de la propia organización o el proveedor o proveedores que dan servicio a equipos desde los que se ha originado un ataque contra la organización. Del mismo modo, en algunos casos será recomendable contactar con los fabricantes de hardware y/o software que se hayan visto involucrados en el incidente, debido a una vulnerabilidad o una mala configuración de sus productos. También debe haber una comunicación con terceros, tanto en el caso de que pudieran haber sido perjudicados por la intrusión, como si hubieran utilizado ordenadores de la organización para realizar un ataque contra sistemas 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. Por último, en algunos casos será conveniente definir un Plan de Comunicación con los Medios (agencias de noticias, emisoras de radio y televisión…). Para ello, la organización deberá establecer quién se encargará de hablar con dichos medios y qué datos se podrán facilitar en cada momento. Cabe mencionar, que en esta comunicación deberán evitarse en la medida de lo posible especulaciones y no revelar información sensible, así como las causas y responsables del incidente.

UNIDAD DIDÁCTICA 10. ESTABLECIMIENTO DEL PROCESO DE CIERRE DEL INCIDENTE Y LOS REGISTROS NECESARIOS PARA DOCUMENTAR EL HISTÓRICO DEL INCIDENTE. Etapas finales del proceso de incidentes. Tras haber aislado los equipos, haber capturado y protegido la información asociada con el incidente, haberla catalogado y almacenado para preservar las evidencias, haber caracterizado el tipo de incidente o intento de intrusión, haber comunicado con todas las personas y organismos que deben ser informados y haber investigado y aplicado soluciones de emergencia, se podría decir que nos encontramos ante la fase final de proceso de gestión de incidentes. Esta fase comenzará con la eliminación de todos los medios posibles que faciliten una nueva intrusión en el sistema, es decir, cambiar todas las contraseñas de los equipos a los que hayan podido tener acceso atacantes o usuarios no autorizados, revisar la configuración de los equipos, detectar y anular los cambios realizados por los atacantes en los equipos afectados, restaurar programas ejecutables y ficheros binarios (como las librerías del sistema) desde copias seguras y mejorar, si es posible, los mecanismos de registro de la actividad en estos equipos. Como último paso, se debería recuperar una actividad normal en los sistemas afectados, reinstalando las aplicaciones y servicios, incluyendo parches y actualizaciones de seguridad, restaurando datos de los usuarios y aplicaciones desde las copias de seguridad, recuperando las conexiones y los servicios de red y verificando una correcta configuración de estos equipos. Una vez restaurada la actividad normal se deberá hacer un seguimiento a posteriori del incidente. Se deberán identificar las lecciones y principales conclusiones de cada incidente, recurriendo al análisis posterior de los equipos afectados por el incidente y entrevistando a las personas implicadas en la gestión del incidente. Se deberán recoger mejoras de la seguridad propuestas como consecuencia de las “lecciones aprendidas” en cada incidente, revisando así, las políticas y procedimientos de seguridad, realizando un nuevo análisis detallado de las vulnerabilidades y riesgos del sistema y demás procedimiento relevantes para evitar que una intrusión vuelva a tener lugar.

Documentación del incidente de seguridad. El Plan de Respuesta a Incidentes debería establecer cómo se tiene que documentar un incidente de seguridad, reflejando de forma clara y precisa aspectos como lo 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.

La Trans-European and Education Network Association (TERENA) ha desarrollado un estándar para facilitar el registro e intercambio de información sobre incidentes de seguridad: el estándar RFC 3067, con recomendaciones sobre la información que debería ser registrada en cada incidente (Incidente Object Description and Exchange Format Requirements). Conviene destacar que una correcta y completa documentación del incidente facilitará el posterior estudio de cuáles han sido sus posibles causas y sus consecuencias en el sistema informático y los recursos de la organización. Por supuesto, será necesario evitar que el personal no autorizado pueda tener acceso a esta documentación sensible.

MÓDULO 6: ANÁLISIS FORENSE INFORMÁTICO.

UNIDAD DIDÁCTICA 1. CONCEPTOS GENERALES Y OBJETIVOS DEL

ANÁLISIS FORENSE.

El análisis forense es una metodología de estudio ideal para el análisis posterior de incidentes, mediante el cual se trata de reconstruir cómo se ha penetrado en el sistema, a la par que se valoran los daños ocasionados. Si los daños han provocado la inoperabilidad del sistema, el análisis se denomina análisis postmortem. A continuación, presentamos el siguiente esquema, en el que podemos observar la relación que podemos encontrar entre la gestión de incidentes de la que hablábamos en anteriores módulos y el análisis forense del presente.

En el desglose del concepto de Análisis forense, podemos distinguir varios que se encuentran íntimamente relacionados con la gestión de incidentes de seguridad

informática. A continuación, explicaremos algunos conceptos básicos en este campo. Ciencia Forense. La Ciencia Forense nos proporciona los principios y técnicas que facilitan la investigación de los delitos criminales, mediante la identificación, captura, reconstrucción y análisis de las evidencias. Al fin y al cabo, es la aplicación de técnicas científicas y analíticas especializadas a infraestructura tecnológica que permiten identificar, preservar, analizar y presentar datos que sean válidos dentro de un proceso legal. La Ciencia Forense recurre a la aplicación de un método científico para analizar las evidencias disponibles y formular hipótesis sobre lo ocurrido. El trabajo de la Ciencia Forense se basa en el “Principio de Transferencia de Locard” según el cual cualquier persona u objeto que entra en la escena del crimen deja un rastro en la escena o en la propia víctima, y viceversa, es decir, también se lleva consigo algún rastro de la escena del crimen. (Este principio será más desarrollado en la siguiente unidad didáctica). La ciencia forense nos proporciona los principios y técnicas que facilitan la investigación del delito criminal, en otras palabras: cualquier principio o técnica que puede ser aplicada para identificar, recuperar, reconstruir o analizar la evidencia durante una investigación criminal forma parte de la ciencia forense. Los principios científicos que hay detrás del procesamiento de una evidencia son reconocidos y usados en procedimientos como:

Recoger y examinar huellas dactilares y ADN.

Recuperar documentos de un dispositivo dañado.

Hacer una copia exacta de una evidencia digital.

Generar una huella digital con un algoritmo.

Firmar digitalmente un documento para poder afirmar que es auténtico y preservar la cadena de evidencias.

Un forense aporta su entrenamiento para ayudar a los investigadores a reconstruir el crimen y encontrar pistas. Aplicando un método científico analiza las evidencias disponibles, crea hipótesis sobre lo ocurrido para crear la evidencia y realiza

pruebas, controles para confirmar o contradecir esas hipótesis. Esto puede llevar a una gran cantidad de posibilidades sobre lo que pudo ocurrir, esto es debido a que un forense no puede conocer el pasado, no puede saber qué ocurrió ya que sólo dispone de una información limitada. Por esto, sólo puede presentar posibilidades basadas en la información limitada que posee. Un principio fundamental en la ciencia forense, que usaremos continuamente para relacionar un criminal con el crimen que ha cometido, es el Principio de Intercambio o transferencia de Locard, (Edmond Locard, francés fundador del instituto de criminalística de la universidad de Lion, podemos ver el esquema en la figura. Informática forense. Por su parte, la Informática Forense se encarga de adquirir, preservar, obtener y presentar datos que han sido procesados electrónicamente y guardados en un medio computacional. La informática forense hace entonces su aparición como una disciplina auxiliar de la justicia moderna, para enfrentar los desafíos y técnicas de los intrusos informáticos, así como garante de la verdad alrededor de la evidencia digital que se pudiese aportar. Desde 1984, el Laboratorio del FBI y otras agencias que persiguen el cumplimiento de la ley empezaron a desarrollar programas para examinar evidencia computacional. Para poder realizar este trabajo resultará fundamental contar con los medios y el material especializado para las distintas técnicas del análisis forense así como disponer de un manual detallado de los procedimientos de actuación, definiendo de forma clara y precisa todas las actividades que se realizarán en cada una de las etapas del análisis forense en sistemas informáticos. Es necesario recalcar que, un equipo de análisis forense ha de estar constituido por expertos con los conocimiento, experiencia y actitudes necesarias para el desarrollo de estas actividades. Además, sus miembros deberían contar con el entrenamiento adecuado, prestando especial atención a la puesta al día de sus conocimientos y habilidades. Dentro de los objetivos de la informática forense podemos recalcar los siguientes:

La compensación de los daños causados por los criminales o intrusos.

La persecución y procesamiento judicial de los criminales.

La creación y aplicación de medidas para prevenir casos similares.

Estos objetivos son logrados de varias formas, entre ellas, la principal es la recolección de evidencia.

Por otra parte, existen varios usos de la informática forense, muchos de estos usos provienen de la vida diaria, y no tienen que estar directamente relacionados con la informática forense:

Prosecución Criminal. Evidencia incriminatoria puede ser usada para procesar una variedad de crímenes, incluyendo homicidios, fraude financiero, tráfico y venta de drogas, evasión de impuestos o pornografía infantil.

Litigación Civil. Casos que tratan con fraude, discriminación, acoso, divorcio, pueden ser ayudados por la informática forense.

Investigación de Seguros. La evidencia encontrada en computadores, puede ayudar a las compañías de seguros a disminuir los costos de los reclamos por accidentes y compensaciones.

Temas corporativos. Puede ser recolectada información en casos que tratan sobre acoso sexual, robo, mal uso o apropiación de información confidencial o propietaria, o aún de espionaje industrial.

Mantenimiento de la ley. La informática forense puede ser usada en la búsqueda inicial de órdenes judiciales, así como en la búsqueda de información una vez se tiene la orden judicial para hacer la búsqueda exhaustiva.

Podemos señalar que una interesante referencia para el análisis forense en los sistemas informáticos es la guía “Best Practices for Seizing Electronic evidence”, publicada por el Servicio Secreto de Estados Unidos y accesible en Internet.

Otros conceptos generales. Algunos conceptos generales que debemos de tener en cuenta para comprender el presente módulo de Análisis forense informático son los siguientes: Cadena de Custodia: Supone la identidad de personas que manejan la evidencia en el tiempo del suceso y la última revisión del caso. Es responsabilidad de la persona que maneja la evidencia asegurar que los artículos son registrados y contabilizados durante el tiempo en el cual están en su poder, y que son protegidos, llevando un registro de los nombres de las personas que manejaron la evidencia o artículos con el lapso de tiempo y fechas de entrega y recepción. Imagen Forense: Llamada también "Espejo", la cual es una copia bit a bit de un medio electrónico de almacenamiento. En la imagen quedan grabados los espacios que ocupan los archivos y las áreas borradas incluyendo particiones escondidas. Análisis de Archivo: Examina cada archivo digital descubierto y crea una base de datos de información relacionada al archivo (metadatos, etc.), consistente entre otras cosas en la firma del archivo o hash (indica la integridad del archivo), autor, tamaño, nombre y ruta, así como su creación, último acceso y fecha de modificación.

UNIDAD DIDÁCTICA 2. EXPOSICIÓN DEL PRINCIPIO DE LOCKARD.

Este principio fundamental viene a decir que cualquiera o cualquier objeto que entra en la escena del crimen deja un rastro en la escena o en la víctima y viceversa (se lleva consigo), en otras palabras: “cada contacto deja un rastro”. En el mundo real significa que si piso la escena del crimen con toda seguridad dejaré algo mío ahí, pelo, sudor, huellas, etc. Pero también me llevaré algo conmigo cuando abandone la escena del crimen, ya sea barro, olor, una fibra, etc. Con algunas de estas evidencias, los forenses podrán demostrar que hay una posibilidad muy alta de que el criminal estuviera en la escena del crimen. En este ejemplo hemos hablado de evidencias físicas, en la ciencia forense tradicional hay varios tipos de evidencias físicas:

Evidencia transitoria: como su nombre indica es temporal por naturaleza, por ejemplo un olor, la temperatura, o unas letras sobre la arena o nieve (un objeto blando o cambiante).

Evidencia curso o patrón: producidas por contacto, por ejemplo la trayectoria de una bala, un patrón de rotura de un cristal, patrones de posicionamiento de muebles, etc.

Evidencia condicional: causadas por una acción o un evento en la escena del crimen, por ejemplo la localización de una evidencia en relación con el cuerpo, una ventana abierta o cerrada, una radio encendida o apagada, dirección del humo, etc.

Evidencia transferida: generalmente producidas por contacto entre personas, entre objetos o entre personas y objetos. Aquí descubrimos el concepto de relación.

El principio de intercambio de Lockard se puede resumir así:

El sospechoso se llevará lejos algún rastro de la escena y de la víctima.

La víctima retendrá restos del sospechoso y puede dejar rastros de si mismo en el sospechoso.

El sospechoso dejará algún rastro en la escena.

El objetivo es establecer una relación entre los diferentes componentes:

La escena del crimen.

La víctima.

La evidencia física.

El Sospechoso. Para la correcta resolución del caso, todos estos componentes deben estar relacionados. Esto se conoce como el concepto de relación, que es lo que nos faltaba para completar el principio de intercambio de Lockard. Las evidencias pueden, a su vez, ser transferidas de dos formas distintas:

Transferencia directa: cuando es transferida desde su origen a otra persona u objeto de forma directa.

Transferencia indirecta: cuando es transferida directamente a una localización y, de nuevo, es transferida a otro lugar.

En este primer esquema, se muestran los conceptos básicos del principio de

lockard.

En este segundo esquema, los mismos principios, en la versión digital que nos

ocupa.

UNIDAD DIDÁCTICA 3. GUÍA PARA LA RECOGIDA DE EVIDENCIAS

ELECTRÓNICAS.

Evidencias volátiles y no volátiles.

Una evidencia es toda aquella información que podrá ser capturada y analizada posteriormente para interpretar de la forma más exacta posible el incidente de seguridad: en qué ha consistido, qué daños ha provocado, cuáles son sus consecuencias y quién pudo ser el responsable. También, se pueden considerar como evidencias los campos magnéticos y los pulsos electrónicos emitidos por los equipos informáticos. Las evidencias digitales se clasifican en dos tipos: volátiles y no volátiles. Las evidencias volátiles son aquellas que se pierden al apagar el equipo, (por ejemplo, el estado de la memoria, los procesos de ejecución, conexiones de red etc.); y las evidencias no volátiles son aquellas que se encuentran almacenadas en el sistema de ficheros, (por ejemplo un programa etc.) La mejor forma es recoger las evidencias del equipo siguiendo la normativa RFC 3227. En la siguiente dirección se puede encontrar: http:lltools.ietf.orglhtmllrfc3227 Dicha normativa establece el siguiente orden de volatibilidad de las evidencias:

Registros, caché.

Tabla de enrutado, caché arp, tabla de procesos, estadísticas del kernel y memoria.

Ficheros temporales del sistema.

Discos duros.

Registros y datos de monitorización remotos que sean relevantes para el sistema en cuestión.

Configuración física y topología de la red.

Etiquetado de evidencias A pesar de ser intangibles, las evidencias digitales o electrónicas pueden ser admitidas como prueba en un juicio, si se ofrecen unas determinadas garantías en las distintas etapas del análisis forense, mediante el aislamiento de la escena del crimen para evitar la corrupción de ésta y de las posibles evidencias que en ella puedan hallarse. Debemos tener en cuenta, por lo tanto, que el proceso de captura de evidencias digitales no debe alterar el escenario objeto de análisis. En la práctica esto es muy difícil de conseguir, ya que las herramientas utilizadas van a modificar la memoria del sistema informático en el que se ejecutan. De hecho, la ejecución de determinados comandos en el sistema podría alterar la información registrada en el disco. Así, por ejemplo, un simple listado del contenido de un directorio va a modificar la fecha del último acceso a cada fichero. No es recomendable emplear las propias herramientas del sistema, ya que éstas podrían haber sido manipuladas por terceros, mediante rootkits o troyanos. Así mismo, es necesario emplear medios estériles para guardar una copia de las evidencias digitales, es decir, medio que no hayan tenido datos previos en ellos; de igual manera es conveniente obtener la imagen fotográfica de todas las pantallas que muestra el sistema informático durante el proceso de captura de las evidencias digitales. La captura de las evidencias digitales se complica aún más con las evidencias volátiles, entendiendo como tales a toda aquella información que se perderá al apagar un equipo informático objeto de análisis. Podemos considerar la siguiente relación de evidencias digitales volátiles:

Volcado de la memoria global del sistema y de cada proceso: ante la dificultad de realizar un análisis en profundidad, se podrá utilizar el volcado de memoria para buscar determinadas cadenas de caracteres que puedan dar pistas sobre el incidente que ha afectado al equipo.

Procesos y servicios en ejecución dentro del sistema, siendo conveniente identificar de cada uno de ellos el fichero ejecutable, los parámetros de ejecución etc.

Controladores (drivers) instalados para gestionar distintos recursos hardware del sistema.

Usuarios y grupos de usuarios activos dentro del sistema: qué sesiones se encuentran abiertas en el momento de llevar a cabo el análisis del equipo.

Tras haber capturado todas las evidencias volátiles, se procederá a obtener la información de los discos duros del sistema. Para ello conviene apagar de forma repentina el equipo, de modo que se pueda evitar que en el proceso de apagado desde el sistema operativo se puedan borrar algunas evidencias, ya que el atacante podría haber incluido alguna rutina para eliminar evidencias de sus actuaciones dentro del sistema cuando éste fuera apagado. Cadena de custodia. Es la compuesta por el conjunto de procedimientos, los funcionarios y la documentación relacionada ala colectación, envió, traslado y verificación científica de la evidencia. ¿Cuándo comienza la cadena de custodia? Desde el momento en que es colectada y termina con la sentencia. En realidad cuando se levanta el acta descriptiva del sitio del suceso y en donde se relacionan todos los objetos colectados comienza la cadena de custodia. Allí comenzó la cadena de custodia. El funcionario la entrega mediante una planilla de recepción a objetos recuperados y ese documento es parte de la cadena de custodia, es decir, que tanto el funcionario que la colectó como el documento que la identifica y el procedimiento que empleó forman parte de la cadena de custodia.

Y si las evidencias de las que hablamos son de tipo digital, es igualmente necesario contemplar una serie de tareas de tipo técnico y de medidas de carácter organizativo, teniendo en cuenta las recomendaciones de la IOCE (International Organization on Computer Evidence).

Así, en primer lugar, se deberá utilizar un adecuado método de identificación, precinto, etiquetado y almacenamiento de las evidencias, considerando la posible incorporación de una firma temporal (digital timestamp) en cada evidencia para que quede registrado el momento en que fue capturada.

Estas evidencias digitales deberán ser preservadas de factores ambientales adversos: campos magnéticos, fuentes de radiación, etc. Por este motivo, se recomienda conservar los soportes informáticos donde se han registrado las evidencias digitales en bolsas de plástico antiestáticas.

Así mismo, es necesario garantizar que los datos digitales adquiridos de copias no puedan ser alterados, por lo que para su obtención se deberían emplear herramientas de generación de imágenes bit a bit, que incorporen códigos de comprobación (checksums o algoritmos de huella digital como SHA-i o MDS) para facilitar la comprobación de la integridad de estos datos.

Otro aspecto de gran importancia es la documentación de todo el proceso de adquisición de evidencias, llevado a cabo por profesionales con los conocimientos adecuados. En dicha documentación se debe reflejar de forma clara y precisa la identificación de las personas que intervienen en el proceso, así como el momento y lugar en que se captura cada una de las evidencias. También se puede prever la posibilidad de realizar una grabación en vídeo por parte del equipo encargado de la captura de evidencias digitales.

Por último, resultará fundamental, sobre todo desde un punto de vista legal, el mantenimiento de la cadena de custodia de las evidencias. Con tal motivo, deben estar perfectamente definidas las obligaciones y funciones de cada uno de los miembros del equipo de análisis forense. Ficheros y directorios ocultos. La tarea de análisis de los ficheros se puede ver dificultada por el hecho de que algunos de estos ficheros se encuentren comprimidos y/o cifrados. En éste último caso resultará mucho más difícil el análisis si se ha utilizado un algoritmo de cifrado robusto. Del mismo modo, será difícil localizar y analizar los ficheros ocultos mediante distintas técnicas dentro del sistema:

Activación del atributo “oculto” en las propiedades de algún fichero para que no sea mostrado por el sistema operativo.

Información y ficheros ocultos en otros ficheros mediante técnicas esteganográficas.

Mecanismo ADS (Alternative Data Streams) del sistema de ficheros NTFS de Windows, utilizado para mantener información sin estructura asociada a un fichero (un icono, por ejemplo). No obstante, este mecanismo puede ser empleado por un intruso para ocultar archivos asociados a otros sin que sean detectados por el administrador del sistema.

El análisis de informática forense es siempre útil en aspectos que aparentemente parecen poco relacionados con los ordenadores. En algunos casos, la información personal en un ordenador, por ejemplo, en un caso de divorcio, el esposo puede haber escondido fondos mancomunados en una cuenta de banco secreta. Aunque en los casos mencionados se ha borrado la información que tienen en sus ordenadores, el especialista en Informática Forense puede recuperar esta información de los discos duros de los ordenadores.

Pero, ¿cómo es posible recuperar información o evidencia borrada? El sistema operativo de un ordenador utiliza un directorio que contiene el nombre y la ubicación de cada archivo en el disco duro. Cuando un archivo es borrado, varios eventos tienen lugar en un ordenador. Un archivo marcador de status es revelado para indicar que un archivo ha sido borrado. Un marcador de estado del disco es revelado para indicar que el espacio es ahora disponible para uso. Así, el usuario no puede ver el archivo listado en ningún directorio, pero en realidad nada se ha hecho al archivo. Este nuevo espacio es denominado espacio libre o no usado, hasta que otro archivo reescriba sobre este espacio; el especialista en Informática Forense puede recuperar este archivo en su integridad. El sobreescribir sobre el archivo puede ser causado por una variedad de actividades del usuario, entre ellas añadir un nuevo programa o crear nuevos documentos que son archivados donde el archivo "borrado" está. Sólo cuando la información es sobreescrita por nueva información, esa parte o todo el archivo no es más recuperable a través de técnicas de informática forense. El espacio libre o disponible para uso en los discos duros de los ordenadores es dividido en sectores de igual tamaño. Cuando el usuario necesita almacenar información, el sistema operativo del ordenador automáticamente determina cuál de esos sectores será utilizado para almacenar esta información. En muchos casos, la información a ser almacenada no utiliza todo el espacio disponible en el sector o sectores designados. Cuando esto sucede, la información que fue previamente almacenada en el disco duro, permanece en el sector no usado al que lo denominan "sector inactivo". Lo cual implica que si parte del disco ha sido sobreescrito con nueva información, hay todavía la posibilidad de que alguna evidencia incriminante todavía quede en ese sector inactivo. Información importante o crítica para algún caso puede ser también recuperable a través de las diferentes técnicas de informática forense. Esta información oculta o no visible para el usuario, está llena de detalles sobre el uso del ordenador, como pueden ser páginas web visitadas, e-mail enviado y recibido, información sobre transacciones bancarias realizadas a través de Internet, documentos, cartas y fotografías que fueron creadas, modificadas o visitadas en muchos de los casos, inclusive si esta información no fue guardada en el ordenador por el usuario. Recuperación de ficheros borrados. Por la forma de almacenamiento de los discos duros, cuando un archivo es borrado de la papelera de reciclaje no desaparece totalmente. Los archivos eliminados son simplemente marcados como tales y la información puede recuperarse bajo ciertas condiciones.

Cuando un archivo se borra de la papelera de reciclaje, el sistema sólo lo marca como eliminado y, por lo tanto, queda físicamente en el disco duro, pero no es más visible por el usuario. La información del fichero, en estas condiciones, puede verse afectada en cualquier momento, puesto que otro archivo nuevo puede reemplazarla físicamente en el disco. A veces, un archivo puede recuperarse íntegramente o sólo partes, dependiendo si fue o no reemplazado físicamente en el disco duro por otra información. Un fichero puede borrarse manualmente al vaciar la papelera de reciclajes o al ser eliminado directamente; pero también puede verse eliminado por un virus, por programas liberadores de espacio que lo consideraron poco importante, etc. Por lo tanto es siempre útil tener una herramienta recuperadora a nuestro alcance. En relación al análisis forense, su equipo, debe tener especial cuidado a la hora de localizar aquellos ficheros marcados como borrados en el disco pero que todavía no habían desaparecido de este, es decir, los sectores que todavía no habían sido asignados a otros ficheros, por lo que formaban parte del free space (espacio libre del disco). Con las herramientas adecuadas también es posible recuperar fragmentos de antiguos ficheros, además de facilitar el análisis de los datos que pudieran encontrarse en los espacios de separación entre particiones y sectores, así como en el espacio no utilizado dentro de cada sector (slack space). En la dirección de los campos reservados en el sistema de archivos y los espacios etiquetados como dañados por el sistema de archivos.

UNIDAD DIDÁCTICA 4. GUÍA PARA EL ANÁLISIS DE LAS EVIDENCIAS ELECTRÓNICAS RECOGIDAS, INCLUYENDO EL ESTUDIO DE FICHEROS Y DIRECTORIOS OCULTOS, INFORMACIÓN OCULTA DE SISTEMA Y LA RECUPERACIÓN DE FICHEROS BORRADOS. El análisis de las evidencias digitales capturadas en las etapas anteriores podría ser realizado mediante herramientas especializadas (como EnCase) que permiten analizar la imagen obtenida de los discos duros sin tener que volcarla a otro disco o unidad de almacenamiento. La labor de análisis puede comenzar con la búsqueda de Información (cadenas de caracteres alfanuméricos) en el volcado de la memoria del sistema o en las imágenes de los discos duros para localizar ficheros sospechosos, como podrían ser programas ejecutables, scripts o posibles troyanos. A continuación, se podrán ejecutar estos ficheros sospechosos en un entorno de pruebas totalmente controlado (por ejemplo, en una máquina virtual creada mediante la herramienta VMware con la misma configuración que el sistema que ha sufrido el incidente), para estudiar su comportamiento: interacción con el sistema, llamadas a otras aplicaciones o ficheros que intenta modificar (para esto último se pueden emplear herramientas como Filemon o Regmon en los sistemas Windows). Así mismo, se tendrá que realizar una comprobación de la integridad en los ficheros y librerías del sistema, para detectar posibles manipulaciones (presencia de rootkits en el sistema). Para ello, será necesario disponer de la información sobre el estado del sistema previo al incidente (firmas digitales de los ficheros y librerías, mediante algoritmos como SHA-1 o MD5). También es posible consultar una base de datos de firmas para instalaciones típicas de distintos sistemas operativos, como la base de datos NSRL (National Software Reference Library) del Instituto de Estándares NIST de Estados Unidos (www,nsrl,nist,gov). El análisis de las evidencias también debe contemplar la revisión de los ficheros de configuración del sistema, donde se establecen los parámetros básicos del arranque, los servicios que se van a ejecutar y las directivas de seguridad, por este motivo, será necesario comprobar la ejecución programada de aplicaciones, así como revisar la configuración de las aplicaciones servidoras que se ejecutaban en el sistema informático objeto de estudio (servidor WWW, servidor FTP…) y los registros de actividad de estas aplicaciones (logs). Se debería tener en cuenta, además, la posibilidad de obtener datos adicionales de los logs de otros equipos y dispositivos de la red (como, por ejemplo, los cortafuegos o los IDS) para llevar a cabo un análisis más completo de estos registros de actividad.

En relación con los ficheros incluidos en la copia del disco o discos del sistema, conviene realizar las siguientes tareas:

Identificación de los tipos de archivos, a partir de sus extensiones o del estudio de los "números mágicos" (Magic Numbers), es decir, de la información contenida en la cabecera de cada fichero.

Visualización del contenido de los ficheros gráficos.

Estudio de las fechas de creación, cambio y último acceso a los ficheros, para detectar qué ficheros han experimentado cambios o han sido creados en las fechas próximas al incidente. Hay que tener en cuenta la fecha y hora del sistema en el momento de obtener las evidencias.

Revisión de los permisos de acceso y ejecución de los ficheros, así como de la información sobre quiénes son sus propietarios.

Revisión de los distintos ficheros temporales obtenidos en la imagen del sistema: memoria temporal (caché) del navegador, direcciones URL que se han tecleado en la caja de direcciones, contenido del historial del navegador, caché del protocolo ARP, archivo de paginación del sistema (swap), spooler de impresión, etc.

La tarea de análisis de los ficheros se puede ver dificultada por el hecho de que algunos de estos ficheros se encuentren comprimidos y / o cifrados. En este último caso resultará mucho más difícil el análisis si se ha utilizado un algoritmo de cifrado robusto.

UNIDAD DIDÁCTICA 5. GUÍA PARA LA SELECCIÓN DE LAS HERRAMIENTAS DE ANÁLISIS FORENSE. Las herramientas de análisis forense permiten asistir al especialista durante el análisis de un delito informático, automatizando buena parte de las tareas descritas en los apartados anteriores para facilitar la captura, preservación y posterior análisis de las evidencias digitales. Además, se distinguen por su capacidad para trabajar con distintos sistemas de ficheros: FAT y FAT32, NTFS de Windows, Ext2l3 de Linux, HFS de Macintosh, etcétera. De las herramientas de análisis forense disponibles en el mercado podríamos considerar que las más populares serian:

EnCase. Es un producto de Guidance Software utilizado para analizar los medios de comunicación digitales (por ejemplo, en las investigaciones civiles, penales, las investigaciones de la red, el cumplimiento de datos y descubrimiento electrónico). EnCase incluye herramientas para la adquisición de datos, recuperación de archivos, indexación, búsqueda y análisis de archivos.

The Forensic Toolkit. FTK es un programa informático forense realizado por AccessData. Analiza una unidad de disco duro en busca de información diversa es decir, puede localizar los correos electrónicos eliminados y escanear un disco de cadenas de texto para usarlos como un diccionario contraseña para romper el cifrado. El paquete también incluye un programa de imágenes de disco independiente llamado FTK imagen.

The Coroner's Toolkit. The Coroner's Toolkit (TCT) es un kit de utilidades desarrolladas por Dan Farmer y Wietse Venema para el análisis post-mortem de un sistema. Este kit fue mostrado por primera vez en una clase de análisis forense de computadoras en agosto de 1999. Sus características más destacadas son entre otras la captura de información (grave – robber) y la muestra de patrones de acceso de archivos existentes o borrados (dead or alive).