SOBRE CANALES OCULTOS, SECRETOS, LATERALES. Y NO SOLO..

ACERCA DE CANALES LATERALES, SECRETOS Y OCULTOS . Y NO SÓLO…

ACERCA DE CANALES OCULTOS, SECRETOS Y LATERALES. Y NO SÓLO

V.A. Galatenko (Doctor en Ciencias Físicas y Matemáticas)

Acerca de los canales ocultos

Esta no es la primera vez que Jet Info aborda el tema de los canales ocultos. En 2002 se le dedicó un número aparte (ver [1], [2]), por lo que este trabajo supone que el lector está familiarizado con los conceptos básicos de este campo del conocimiento; en caso contrario, se recomienda releer el artículo [2]. Sin embargo, el autor quisiera señalar desde el principio que el tema de los canales ocultos en su interpretación tradicional le parece algo inverosímil y formal. La investigación de canales encubiertos alcanzó su punto máximo a mediados de la década de 1980 con la publicación del Libro Naranja. El Departamento de Defensa de EE. UU., que, a partir de la clase de seguridad B2, introdujo el requisito de análisis de canales encubiertos. Como resultado, la lucha contra los canales ocultos comenzó principalmente no por el bien de la seguridad real, sino por el bien de una certificación exitosa. Además, los canales encubiertos, debido a su asociación generalmente aleatoria con las clases B2 y superiores, se han estudiado casi exclusivamente en el contexto de políticas de seguridad multinivel, con la mención obligatoria de temas ALTOS y BAJOS, modelos de no influencia y otras complejidades. . Todo esto está infinitamente lejos de los problemas reales de los típicos sistemas de información modernos, y los resultados publicados son en su mayor parte obvios y no tienen interés teórico ni, especialmente, práctico. El artículo [2] explica las razones conceptuales de esta situación.

En particular, no es aconsejable plantearse la cuestión de la posibilidad de organizar canales encubiertos para controlar un sistema hostil de múltiples agentes (AMAS). Si el VMAS se construyó pirateando muchos sistemas remotos e introduciendo en ellos software malicioso (malware), entonces, obviamente, se encontraron para ello recursos de comunicación con el secreto adecuado, más que suficientes para su posterior gestión.

A mediados de la década de 1980, se propuso una metodología sistemática para identificar canales encubiertos de la memoria (ver [3]), cuyo elemento clave es una matriz de recursos compartidos. En un entorno de red, en Internet, existen tantos recursos legales compartidos como se desee; por ejemplo, el espacio asignado a los usuarios en sitios públicos. Puede utilizar tanto los campos del encabezado del paquete IP (la suma de comprobación, por ejemplo, es un excelente candidato para esta función) como los números de secuencia iniciales al establecer una interacción TCP (consulte [4]). También se pueden organizar canales encubiertos prácticos por tiempo, por ejemplo, codificando una unidad enviando un paquete en un intervalo de tiempo determinado de milisegundos (ver [5]).

Con la llegada de potentes sistemas multiprocesador con memoria compartida, el ancho de banda de los canales encubiertos ha saltado a megabits por segundo y continúa aumentando con la velocidad del hardware (ver [6]). Esto, por supuesto, es un problema grave, pero para solucionarlo basta con abandonar la división de este tipo de sistemas entre sujetos con diferentes niveles de autorización.

El problema de los canales encubiertos es una manifestación de un problema más general de la complejidad de los sistemas de información modernos. En los sistemas complejos hubo, hay y habrá canales ocultos, por lo que es necesario luchar contra la causa, no contra el efecto. En su forma más general, el método para abordar la complejidad de los sistemas puede formularse como “llevar a cabo un enfoque basado en objetos con límites físicos entre objetos”. Los procesadores no deben compartirse no sólo entre sujetos, sino también entre subprocesos de control. La red de usuarios debe estar físicamente separada de la red administrativa. En términos generales, los componentes del sistema no deben confiar entre sí: es posible que el procesador no confíe en la memoria, que la tarjeta de red no confíe en el procesador, etc. Cuando se detecta actividad sospechosa, los componentes deben dar la alarma y aplicar otras medidas de protección (por ejemplo, un controlador de disco puede cifrar archivos, un controlador de red puede bloquear las comunicaciones, etc.). En general, en una guerra es como en una guerra. Si es imposible organizar límites físicos, conviene utilizar límites virtuales, formados principalmente por medios criptográficos. Una presentación más detallada de estos temas se puede encontrar en [7].

Los canales ocultos no sólo pueden identificarse, sino también eliminarse o hacerse ruidosos “sin mirar”. Como se explica en [2], para ello se utilizan varios tipos de normalizadores, suavizando la carga del procesador, el consumo de energía, el tiempo de cálculo de determinadas funciones, el tráfico de red, etc. Por ejemplo, el núcleo del sistema operativo Asbestos [8] responde a una solicitud para crear un puerto devolviendo un nuevo puerto con un nombre impredecible, ya que la capacidad de crear puertos con nombres determinados puede servir como un canal encubierto.

Los gastos generales de la normalización pueden ser elevados, lo que puede ralentizar significativamente el funcionamiento de las entidades jurídicas, por lo que se debe buscar y encontrar un compromiso razonable entre la seguridad de la información y la utilidad funcional de los sistemas. Desde el punto de vista de la complejidad, los canales ocultos tienen las siguientes propiedades desagradables. Los recursos compartidos presentes en cualquier nivel del sistema de información, comenzando desde el más bajo, el hardware, se pueden utilizar en todos los niveles superiores, hasta el nivel de aplicación, para organizar la fuga de información. Un árbitro centralizado de acceso a la memoria en un sistema multiprocesador, un caché de segundo nivel compartido por varios procesadores, un dispositivo de administración de memoria: todo esto puede servir como canal de fuga. Por tanto, al analizar los canales encubiertos es necesario considerar el sistema en su conjunto. El intento de realizar la llamada certificación compuesta, en la que un sistema se evalúa basándose en pruebas realizadas previamente de módulos o niveles individuales, conduce a la omisión de canales ocultos. El problema se agrava por el hecho de que en la descripción de módulos o niveles individuales se pueden omitir detalles necesarios por considerarlos poco importantes. Al parecer, ¿qué diferencia hay en cómo se organiza la cola de instrucciones seleccionadas por el microprocesador para su ejecución? Sin embargo, esto también puede ser importante para el funcionamiento seguro de la aplicación (ver [6]). Un sistema operativo que haya superado con éxito la certificación cuando se haya probado en un sistema operativo «desnudo&#187. hardware, contiene canales ocultos de ancho de banda notable si se ejecuta bajo el control de un monitor de máquina virtual. En general, el recurso común es el mismo guisante que una verdadera princesa sentirá a través de cualquier cantidad de colchones de plumas. Y debes recordar esto.

El enfoque del canal encubierto se utiliza activamente para evaluar el grado de imperfección en la implementación de servicios de protección como los anonimizadores y sus redes, así como la reposición del tráfico. Esto parece natural, ya que la anonimización y el enriquecimiento del tráfico son tipos de normalización diseñados para eliminar canales encubiertos. Si la normalización resultó imperfecta, entonces quedan canales ocultos. ¿Qué tan imperfecto? Tan grande como la filtración de información. La imperfección de los anonimizadores puede evaluarse como la capacidad de los canales ocultos para filtrar información sobre el remitente y/o el destinatario (ver [9]). Para anonimizadores individuales, es posible obtener un valor exacto, para redes de anonimizadores, una estimación superior.

Según las tendencias actuales, una parte cada vez mayor del tráfico de Internet está encriptada (ver [10]). El cifrado protege el contenido y los encabezados de los paquetes; el relleno de los paquetes evita que se obtenga información analizando su tamaño. Sin embargo, la criptografía en sí no protege contra el análisis del comportamiento de los paquetes, es decir, su distribución en el tiempo, por lo que la privacidad del usuario puede verse afectada. Además, el análisis de tiempo del tráfico SSH simplifica enormemente el acceso no autorizado a las contraseñas de los usuarios. La reposición de tráfico en la capa de enlace es una medida de protección eficaz contra dicho análisis. El flujo de datos en el canal adquiere un carácter predeterminado. Algunos paquetes se retrasan y se envían datos ficticios al canal cuando es necesario. Eso es básicamente todo. En la práctica, es bastante difícil implementar la reposición de modo que el tráfico observado siga exactamente una distribución predefinida, de modo que el atacante aún pueda correlacionar el tráfico de carga útil reabastecido. La imperfección de la implementación del reabastecimiento se puede evaluar como la capacidad del canal encubierto en función de la variación de los intervalos entre paquetes. Resulta que, en condiciones ideales, este canal encubierto permite un uso práctico. Afortunadamente, en una red realmente ocupada con muchos flujos de datos, un alto nivel de ruido en el canal dificulta la acción de un atacante.

El uso de canales encubiertos para evaluar el grado de imperfección de la arquitectura y/o implementación de servicios de seguridad parece ser un área de investigación muy prometedora.

Los autores de [11] lograron encontrar una aplicación interesante de los métodos de transmisión de datos característicos de los canales de tiempo encubiertos en redes de sensores inalámbricos. Uno de los principales problemas de las redes de sensores es la reducción del consumo energético. Si los valores binarios se transmiten a través de una red inalámbrica de la forma habitual, podemos suponer que para ello se necesita energía proporcional a su logaritmo. Sin embargo, los valores también se pueden transmitir de forma silenciosa: enviar un bit de inicio, lo que hace que el destinatario encienda el contador, esperar el tiempo correspondiente al valor y enviar un bit de parada. Como resultado, se ahorra energía, pero se pierde tiempo (proporcional al valor), pero se puede optimizar la transmisión: el silencio se multiplexa perfectamente, se conecta en cascada y se reenvía rápidamente.

Por supuesto, el método descrito de transmisión de datos pertenece a la categoría de maravillas divertidas. En general, los canales encubiertos son ahora casi exclusivamente un campo de certificación académica. En este contexto, resulta interesante el trabajo [12], en el que se estudia el problema de la integridad del análisis de canales encubiertos. Se introduce el concepto de un conjunto completo de canales ocultos, cuyos elementos juntos generan la máxima fuga de información oculta posible (un análogo del conjunto completo puede ser una base en un espacio vectorial). A medida que se identifican los canales ocultos, se puede verificar que estén completos (utilizando los criterios formulados en [12]) y, como resultado, se puede obtener una evaluación de la posible fuga de información. Otro aspecto muy importante del trabajo [12] es la descripción del enfoque arquitectónico de los sistemas constructivos que facilita el análisis de canales encubiertos. Identificar uno a uno canales ocultos en un sistema de información arbitrario es una tarea inútil; Tiene sentido construir sistemas de alguna manera regular y luego someterlos a un análisis sistemático teniendo en cuenta su especificidad.

En la práctica, ni los atacantes ni los proveedores de seguridad de la información prestan atención notable a los canales encubiertos. La razón es que en los sistemas de información modernos hay más que suficientes datos «bastos&#187. vulnerabilidades que pueden explotarse fácilmente, por lo que tanto los atacantes como los defensores prefieren el camino de menor resistencia, lo cual es bastante natural. Los primeros explotan los “agujeros” obvios, los segundos intentan taparlos.

Los consumidores tampoco tienen tiempo para canales ocultos: les gustaría combatir gusanos y virus mano a mano y encontrar dinero para la nieve del año pasado en paquetes con la etiqueta «sistemas de prevención de intrusiones con firmas conocidas». Y también escuche con paciencia las enseñanzas de los fabricantes de software con fugas por la falta de disciplina a la hora de gestionar numerosos parches correctivos para este mismo software.

Hay dos noticias respecto a vulnerabilidades, ambas buenas. En primer lugar, hay menos problemas de seguridad con el software subyacente, por lo que los atacantes explotan más activamente las vulnerabilidades de las aplicaciones. La segunda noticia es que existen muchas aplicaciones. Pero también existe el phishing y otros métodos de influencia moral y psicológica. Por lo tanto, el momento de los canales ocultos, si llega, no será muy pronto.

Para comprender el modesto lugar que ocupan los canales ocultos entre otros problemas de seguridad de la información, incluso si nos limitamos sólo a los defectos del software, Es aconsejable considerar la clasificación de tales defectos propuesta en el artículo [13] en el contexto del desarrollo de herramientas para el análisis estático de textos fuente con el fin de identificar errores que puedan conducir a vulnerabilidades.

Los defectos en el software pueden introducirse intencionadamente o por negligencia. Los primeros se dividen en maliciosos y no maliciosos. Los defectos maliciosos son puertas traseras, bombas lógicas y bombas de tiempo; no malicioso: canales encubiertos (por memoria o tiempo) y rutas de acceso inconsistentes.

Los defectos introducidos involuntariamente se dividen en:

• errores de validación de datos (errores de resolución, incluidos desbordamientos del buffer, comprobaciones de mala calidad de los valores de los parámetros, colocación incorrecta de las comprobaciones, identificación/autenticación inadecuada);
• errores de abstracción (reutilización de objetos, divulgación de representación interna);
• defectos asincrónicos (problemas de concurrencia, incluidas situaciones de avance, interbloqueos activos y pasivos, espacios entre los tiempos de verificación y uso, y múltiples referencias al mismo objeto);
• uso inadecuado de subcomponentes (fuga de recursos, malentendidos en la distribución de responsabilidades);
• errores de funcionalidad (defectos en el manejo de excepciones, otros defectos de seguridad).

Para comprender cómo se pueden introducir defectos de seguridad en el software de forma intencionada, pero no maliciosa, considere el canal oculto que se forma en el controlador de disco cuando se optimizan las solicitudes de servicio utilizando el algoritmo elevador (las solicitudes de disco no se procesan en el orden en que fueron recibidas, sino según el orden en que fueron recibidas). varilla con cabezas alcanza los bloques solicitados, consulte el artículo [14], que presenta un enfoque sistemático para identificar canales encubiertos a lo largo del tiempo). Un remitente malicioso de información puede influir en el orden y, por tanto, en el tiempo de procesamiento de las solicitudes, controlando la dirección del movimiento de la varilla con cabezales emitiendo sus propias solicitudes al disco en un orden determinado. En este caso, el papel de un recurso compartido que permite la influencia (maliciosa) dirigida es la cola común de solicitudes a los bloques de disco, así como la posición actual y la dirección de movimiento de la varilla. Es natural considerar que este defecto se ha introducido de forma intencionada, pero no maliciosa, ya que el canal oculto no se formó debido a un error de implementación, sino como resultado de una decisión de diseño encaminada a optimizar el funcionamiento del sistema.

El grupo más grande y prácticamente importante de defectos introducidos por negligencia son los errores de validación de datos o, más precisamente, el control insuficiente de los datos de entrada antes de utilizarlos. Desarrollar métodos para prevenir o identificar tales errores es una tarea de suma importancia práctica. Y los canales ocultos pueden esperar…

Acerca de los canales secretos

Como se señala en [15], la llamada seguridad de la información multiaspecto está actualmente se establece cuando se intenta tener en cuenta toda la gama de intereses (a veces en conflicto entre sí) de todos los sujetos de las relaciones de información, así como todo tipo de configuraciones de sistemas de información, incluidos los descentralizados que no tienen un único centro de control. .

La seguridad depende del tema. El usuario tiene su propia seguridad, el proveedor de contenidos tiene la suya propia (y aquí el usuario puede ser considerado un enemigo). Están surgiendo nuevos aspectos de la seguridad, como la gestión de derechos digitales. Esta tendencia es especialmente evidente en el uso de canales secretos.

Recordemos (ver [2]) que los canales de transmisión de información no estándar se consideran ocultos. Los métodos no estándar de transmisión de información a través de canales legales (denominados en este contexto canales envolventes) se denominan canales secretos (canales subliminales) o esteganográficos (canales stego). La información general sobre ellos se proporciona en el artículo [2]. Los backchannels se utilizan cuando existe un canal de comunicación legal, pero algo (por ejemplo, una política de seguridad) prohíbe que cierta información se transmita a través de él.

Tenga en cuenta que existen dos diferencias importantes entre canales encubiertos y secretos. En primer lugar, contrariamente al nombre, nadie intenta ocultar la existencia de canales ocultos; simplemente utilizan entidades que originalmente no fueron diseñadas para este propósito y fueron creadas para otros fines para transmitir información. Por el contrario, un canal secreto existe sólo hasta que el enemigo lo descubre. En segundo lugar, se cree que el tiempo para transmitir información a través de un canal encubierto no está limitado. Por el contrario, el tiempo de transmisión de un canal encubierto está determinado por las características del canal envolvente. Por ejemplo, si se utiliza una imagen gráfica para transmitir información en secreto, entonces solo podrá transmitir lo que se puede colocar en esta imagen sin violar el secreto.

En general, los canales encubiertos son mucho más prácticos que los canales encubiertos porque tienen una base legal: el canal envolvente. Los canales encubiertos (más que encubiertos) son el medio más apropiado para controlar un sistema hostil de múltiples agentes. Pero no sólo los atacantes los necesitan. Los proveedores de contenido pueden utilizar eficazmente los canales de puerta trasera incorporando «marcas de agua digitales&#187 ocultas. y aquellos que deseen controlar su distribución y el cumplimiento de los derechos digitales por parte de los consumidores. Otro ejemplo que se ha convertido en un clásico es el uso de un canal secreto por parte de la Primera Ministra británica Margaret Thatcher, quien, para descubrir cuál de sus ministros era culpable de la filtración de información, les distribuyó versiones de un documento con diferentes espacios entre palabras.

Por supuesto, bajo supuestos muy generales, los canales secretos no sólo no pueden eliminarse, sino incluso detectarse (por ejemplo, en una imagen JPEG comprimida siempre habrá espacio para información oculta). En relación con los canales tanto ocultos como secretos, la afirmación contenida en el artículo [16] “Siempre puedes enviar un poco”.

Una pregunta significativa es la capacidad y estabilidad de dichos canales, que están determinadas no solo por el ancho de banda del canal envolvente y las características de ruido en él, sino también por el tamaño máximo de la carga útil (oculta), así como por la Función detectora de la admisibilidad de la información transmitida (ver, por ejemplo, el artículo [ 17] y las fuentes citadas en el mismo, entre las que destacaremos el trabajo [18]).

El problema de los canales secretos se ha estudiado fructíferamente desde hace mucho tiempo desde la perspectiva de la teoría de la información; se han obtenido muchos resultados teóricamente interesantes y prácticamente importantes. Prestemos atención a la posibilidad y eficacia de compartir canales encubiertos y secretos en un entorno de red. Así, el trabajo [19] describe la implementación de una red de anonimizadores (ver [15]) utilizando servidores y clientes HTTP. La navegación web sirve como un canal envolvente. Los servidores HTTP actúan como nodos en la red anonimizadora, y la interacción entre ellos se lleva a cabo a través de canales ocultos en HTTP/HTML a través de la mediación de clientes desprevenidos (principalmente utilizando medios para redirigir solicitudes y contenido activo, integrados, por ejemplo, en pancartas publicitarias, presente en la página web visitada). Como resultado, es posible lograr no sólo la imposibilidad de asociación entre el remitente y el destinatario de los mensajes, sino también implementar una propiedad más fuerte: el secreto (incluso en presencia de un observador global). Los internautas, que resultan ser intermediarios involuntarios, aumentan el anonimato a analizar, dificultando así al observador la obtención de información útil.

(Por supuesto, tanto los atacantes como los desarrolladores de seguridad son conscientes de las oportunidades y desafíos asociados con el uso de HTTP como canal contenedor. Por ejemplo, [20] describe un sistema de aprendizaje llamado Web Tap que detecta anomalías en las transacciones HTTP salientes).

Observemos también la conexión obvia entre la inteligencia de los agentes integrados (o elementos de un sistema de múltiples agentes) y el rendimiento requerido de canales secretos o encubiertos para interactuar con ellos. La nota [21] proporciona un ejemplo de un programa troyano altamente inteligente, que es un sistema experto integrado en un sistema estratégico confiable (con una política de seguridad de múltiples niveles) para administrar suministros militares y movimientos de tropas y es capaz de determinar a partir de suministros y movimientos si Es probable que las operaciones militares ofensivas comiencen la próxima semana. Si un programa de este tipo transmitiera sólo un bit de información (posible/imposible) cada día, sería muy valioso para la planificación estratégica. Al mismo tiempo, según los requisitos formales del Libro Naranja, los canales encubiertos con un ancho de banda inferior a un bit por diez segundos no pueden considerarse en absoluto al auditar sistemas confiables. (Es un caso raro que el Libro Naranja haga una concesión y, como resulta, es en vano.)

La moraleja es que al analizar los canales secretos y encubiertos en general y su capacidad en particular, es Es necesario tener en cuenta las características específicas de los sistemas de información, el valor de la información y la semántica de la interacción. De lo contrario, los resultados del análisis corren el riesgo de no tener sentido.

Acerca de los canales secundarios

Los canales laterales pueden considerarse un caso especial de canales ocultos. El papel de transmisores (involuntarios) en dichos canales lo desempeñan los componentes estándar de los sistemas de información, y el papel de receptores lo desempeñan observadores externos que utilizan el equipo adecuado. Muy a menudo, los canales laterales se utilizan para medir el tiempo de las operaciones visibles (los ataques temporales a RSA se han vuelto comunes), su consumo de energía y/o las emisiones e interferencias electromagnéticas laterales (PEMIN), pero los canales acústicos también se pueden usar para ataques. ya sea que estemos hablando de una cerradura de seguridad digital o del procesador de una computadora personal que procesa la clave secreta (ver [22]).

Los canales laterales son quizás la manifestación más visible de la naturaleza multifacética de la seguridad de la información moderna. Por regla general, el papel de los atacantes en los sistemas de información (contenidos informativos, tarjetas bancarias, tarjetas SIM de teléfonos móviles, etc.) es el de sus propietarios, que disponen de mucho tiempo y de las herramientas adecuadas. Combinados con la imposibilidad fundamental de controlar el acceso físico, estos factores hacen que los ataques de canal lateral sean especialmente peligrosos.

Los objetivos de los ataques que utilizan canales laterales suelen ser los componentes criptográficos de los sistemas de información o, más precisamente, sus claves secretas. Por ejemplo, el artículo [23] describe un ataque de partición de tarjetas SIM de teléfonos móviles (más precisamente, del algoritmo COMP128 utilizado para la autenticación de usuarios y la generación de claves de sesión), realizado midiendo el consumo de energía para clonar estas tarjetas. ¡El ataque se perfeccionó hasta tal punto que sólo ocho mediciones con datos de entrada seleccionados de forma adaptativa son suficientes para determinar una clave secreta de 128 bits! Es decir, un atacante sólo necesita obtener una tarjeta SIM literalmente durante un minuto.

El peligro de ataques basados ​​en el análisis diferencial del consumo de energía se ilustra muy claramente en el artículo [22]. En 1998, Bruce Schneier escribió que la galaxia no tenía suficiente silicio y el Sol no tenía suficiente vida útil para llevar a cabo un ataque de fuerza bruta a la clave secreta (112 bits) del algoritmo 3DES. La longitud mínima de clave en el algoritmo AES es de 128 bits, pero un ataque exitoso de análisis de potencia diferencial en un chip desprotegido que implementa AES se puede llevar a cabo en menos de tres minutos, desde el inicio de las mediciones hasta el final del análisis.

Una solución fundamental al problema de los canales laterales es posible si se observa el siguiente principio fundamental: los datos de transacciones que se pueden obtener de los canales laterales deben ser estadísticamente independientes de los datos de entrada y salida y de la información restringida. Dado que los sistemas con recursos muy limitados suelen tener que protegerse contra ataques de canales laterales, la implementación correcta y completa del principio cardinal es una tarea muy difícil. El tiempo de operación es relativamente fácil de normalizar, el consumo de energía es más difícil, pero también posible (ver, por ejemplo, [24]), PEMIN es aún más difícil. En la práctica, los sistemas se fortalecen «lo mejor que pueden» (lo cual es típico de la seguridad de la información moderna en general), y los atacantes motivados todavía tienen muchas oportunidades para realizar ataques efectivos.

Acerca de los agentes: los buenos y … diferente

Los agentes y sistemas multiagente (MAS) son una de las áreas en desarrollo activo de la tecnología de programación moderna. Los agentes entregan código a sistemas remotos, lo que amplía la funcionalidad de estos últimos, y los sistemas multiagente permiten paralelizar de forma natural la solución de problemas complejos. Ambas propiedades son importantes, por ejemplo, para una indexación eficiente de recursos multimedia (ver [25]). Los archivos multimedia son grandes y costosos de cargar en un servidor central para su indexación. Es más fácil entregar el código de indexación al sistema de destino y luego recibir desde allí solo los resultados de la indexación, que son de tamaño significativamente más pequeño. Este enfoque también es bueno desde el punto de vista de la seguridad de la información, si se aborda desde la perspectiva de los proveedores de contenidos y la gestión de derechos digitales, ya que elimina la descarga de recursos pagos y, al mismo tiempo, facilita la difusión de información sobre ellos.

Los agentes móviles dependen de interfaces y capacidades que se encuentran en la mayoría de las plataformas. Además, son capaces de pasar de un sistema a otro, moviéndose por la ruta prevista, lo que los hace autónomos y no requieren un control constante, ahorrando así recursos informáticos y de comunicación. En el contexto de la seguridad de la información, los agentes móviles pueden asumir el papel de caballeros andantes, monitoreando los sistemas remotos para la aplicación oportuna de parches correctivos y la ausencia de signos de actividad maliciosa (ver [26]), identificando y reflexionando junto con &# 171;hermanos de armas» ataques distribuidos y coordinados (ver [27]), introduciendo elementos de dinamismo y autoorganización en la defensa (ver [28]).

La incrementalidad es una ventaja importante de los agentes móviles y los sistemas multiagente. Cada agente individual puede resolver su propia tarea privada (seleccionar ciertas propiedades del contenido multimedia, verificar la instalación de ciertas correcciones de software, identificar ciertos tipos de malware, implementar ciertas disposiciones de la política de seguridad), pero su conjunto repuesto resulta ser un Reflexión adecuada y relevante y medios para implementar la política de seguridad actual, cambiando bajo la influencia de cambios en el entorno, con la aparición de nuevos riesgos y amenazas.

La tecnología de agentes móviles y sistemas multiagente es una poderosa herramienta que debe usarse con precaución, siendo conscientes de los riesgos asociados. La vulnerabilidad de las comunicaciones MAC es sólo uno de los problemas, y probablemente no el más difícil. Es necesario tener en cuenta (ver, por ejemplo, [29]) que: 

• los agentes pueden atacar las plataformas de destino (problema de seguridad de la plataforma);
• los propios agentes pueden ser atacados por plataformas, otros agentes y entidades externas como virus (problema de seguridad del agente).

La protección confiable tanto de las plataformas como de los agentes sólo se puede construir teniendo en cuenta la semántica de programas (ver . [2]), pero algunas soluciones privadas se pueden obtener utilizando métodos criptográficos formales, autenticando agentes y sus fuentes, monitoreando la integridad y asegurando la confidencialidad del código y los datos del agente (ver [29], [30], [31]).

Los problemas de seguridad de los agentes móviles y las plataformas de destino se complican especialmente por su influencia mutua. Supongamos que un agente móvil contiene datos confidenciales, de los cuales solo una parte está dedicada a cada plataforma que visita. Estas partes están cifradas con las claves públicas de las respectivas plataformas.

En principio, tanto los agentes como las plataformas pueden realizar el descifrado, pero ambos enfoques tienen desventajas (ver [31]). Si un agente realiza el descifrado, la plataforma debe darle su clave privada, lo cual es (demasiado) arriesgado. Al descifrar utilizando la plataforma, ésta debe conocer la estructura del agente, lo que contradice la movilidad. Además, se deben evitar los intentos de descifrar datos robados a los agentes. La solución de compromiso propuesta en [31] se basa en que la plataforma proporcione algún servicio criptográfico básico, que sólo los agentes autenticados pueden utilizar.

Los agentes tienen un núcleo de “promoción”, que tiene una estructura simple, descifra el cuerpo en una plataforma específica y controla la integridad del resultado.

La coherencia entre la IAU es otra cuestión desafiante. Si los agentes están aplicando una política de seguridad en una gran red corporativa, cuando la política cambia, se debe retirar un conjunto de agentes y se debe lanzar otro conjunto en su lugar. En teoría, todo es sencillo, pero esto puede verse obstaculizado por movimientos asincrónicos de agentes móviles, falta temporal de comunicación con segmentos remotos de la red, etc. En general, el uso adecuado de MAS no es fácil, pero abre muchas oportunidades para agentes maliciosos.

Al igual que los canales encubiertos y encubiertos, el malware debe abordarse: identificarse, eliminarse y/o contenerse. El artículo [2] fundamenta las ventajas del enfoque basado en restricciones, teniendo en cuenta la semántica de los programas y protocolos. En cuanto a la detección, podemos decir que para canales ocultos y secretos generalmente es imposible, y para el malware es aún más inútil. Como muestran los resultados de [32], incluso las mejores herramientas antivirus comerciales ceden ante métodos simples de ofuscación de programas, como, por ejemplo, la reordenación de códigos, un hecho absolutamente obvio y natural desde el punto de vista de la teoría de la información. La situación puede mejorarse hasta cierto punto mediante una comparación más sofisticada con patrones de comportamiento malicioso, como se sugiere en [33], pero esto es una solución «avanzada». de ninguna manera puede considerarse decisivo.

En tales condiciones, sólo nos queda esperar trucos psicológicos infantiles e intentar distraer a los piratas informáticos de Internet proporcionándoles un rincón separado para entretenerse y demostrar su poder (ver [34]), o reducir la probabilidad de que los usuarios lancen malware involuntariamente mediante ampliando el enfoque al gestor de arranque del sistema «todo lo que no está permitido está prohibido» y proteger archivos ejecutables con sumas de verificación criptográficas (consulte [35]).

Acerca de pasajes secretos y agentes de reparación

Si por alguna razón es necesario monitorear constantemente el estado de un sistema remoto y, si es necesario, influir en él, se construyen y utilizan pasajes secretos (puertas traseras). Normalmente, estos movimientos están asociados con actividad maliciosa, pero, como muestra un proyecto desarrollado en la Universidad de Rutgers (ver http://discolab.rutgers.edu/bda/), también existen aplicaciones bastante legítimas para ellos, como monitoreo remoto y recuperación (tratamiento a distancia). En este contexto, conviene denominar a los pasajes secretos interfaces técnicas. El artículo [36] describe un prototipo de implementación de interfaces técnicas para FreeBSD.

Dado que el objetivo final es reparar un sistema objetivo remoto averiado, este último debe considerarse un objeto pasivo. La interfaz propuesta con él se reduce al acceso remoto a la memoria, implementado a través de una tarjeta de red programable. El sistema de destino debe admitir áreas de detección y visualización que puedan leerse para identificar y diagnosticar situaciones anómalas (como falta de progreso de la aplicación, desbordamiento o agotamiento de recursos), así como «reparaciones» — áreas de memoria, cuya escritura puede mejorar la situación (por ejemplo, una tabla de procesos o una copia de un superbloque del sistema de archivos ubicado en la memoria). En principio, si tiene acceso a la memoria del sistema de destino, es posible transferir el servicio que implementa a otro nodo de la red (por ejemplo, dentro de una configuración de clúster) si no se puede realizar la reparación en el sitio (ver [37 ]).

Por supuesto, desde el punto de vista de la seguridad de la información, los pasajes secretos son un medio con efectos secundarios muy graves. Si el sistema de monitoreo se ve comprometido, un atacante puede obtener el control total del sistema objetivo. Interferir con el funcionamiento de una tarjeta de red programable es igualmente peligroso. Como contramedida, dichas tarjetas de red se pueden implementar en un diseño seguro, similar a los criptomódulos, y el control remoto se puede realizar desde varias máquinas y solo con pleno acuerdo en sus acciones.

El enfoque descrito es bueno, en primer lugar, para restaurar la funcionalidad del sistema después de ataques intencionales o no intencionados a la disponibilidad (por ejemplo, cuando se activa una bomba de bifurcación, agotamiento de la RAM o corrupción del sistema de archivos). Si el sistema es pirateado por atacantes y controlado mediante la introducción de malware como rootkits, entonces el sentido común parecería dictar que la única forma de restaurar la confianza en él es una reinstalación completa desde medios seguros garantizados y la posterior aplicación de todos parches correctivos disponibles y también recuperación de datos de usuario no dañados. Sin embargo, en una red corporativa desarrollada, tales actividades pueden requerir un largo trabajo manual por parte de especialistas altamente calificados y pueden resultar económicamente inviables o prácticamente imposibles. En su lugar, puede intentar implementar la idea de la autorreparación automática de los sistemas (es decir, eliminar todo lo malicioso sin perder información benigna) incorporando agentes de reparación en ellos y protegiéndolos mediante tecnología de máquinas virtuales (consulte [38] ).

Los agentes de reparación, al igual que otras herramientas de seguridad de la información, deben satisfacer los siguientes principios de diseño: 

• simplicidad;
• aislamiento (el agente debe estar protegido contra modificaciones o omisiones no autorizadas);
• confianza;
• visibilidad (el agente debe poder ver todo el sistema);
• adaptabilidad (el funcionamiento del agente y la cantidad de recursos que consume debe depender del estado del sistema controlado y no interferir con su funcionamiento normal).

El funcionamiento general de un agente reparador es sencillo. Recuerda el estado seguro conocido del sistema de producción, monitorea todos los cambios realizados, verifica periódicamente si hay signos de comportamiento anómalo y cambios no autorizados y devuelve el sistema a un estado seguro si es necesario. Debido a que el sistema de producción se ejecuta dentro de una máquina virtual, no puede interferir con el agente, que es una extensión del kernel inmutable y confiable.

Por supuesto, en la práctica todo es mucho más complicado. En primer lugar, si un atacante obtiene acceso físico al sistema, podrá evitar al agente de reparación; Puede protegerse de amenazas físicas sólo con la ayuda del soporte de hardware. En segundo lugar, la actividad sospechosa se detecta con cierto retraso, por lo que los datos críticos corren el riesgo de verse comprometidos. En tercer lugar, las sustancias «conocidas por ser seguras» la imagen del sistema puede estar incompleta (el administrador del sistema o el usuario puede agregar o cambiar algo sin pasar por el agente) y entonces los cambios no autorizados no se pueden detectar ni eliminar. La seguridad del sistema no puede exceder el nivel de disciplina existente en la organización y registrado en su política.

La recuperación automática después de un compromiso debería convertirse en uno de los principales objetivos al diseñar e implementar sistemas de información avanzados. Por un lado, hay que aceptar la inevitabilidad de que los ataques tengan éxito, o al menos de que se produzcan fallos de hardware y errores administrativos. Por otro lado, el costo de los equipos, incluidos los medios de almacenamiento, está cayendo rápidamente, por lo que es técnica y económicamente posible organizar un registro detallado del funcionamiento de los sistemas y, en particular, registrar todos los cambios en el sistema de archivos, manteniendo al mismo tiempo la posibilidad de revertir actividades maliciosas o erróneas.

El principal problema es revertir todos los cambios no autorizados sin afectar las modificaciones legales. El artículo [39] describe posibles enfoques para resolver este problema y una implementación prototipo: el sistema de recuperación de intrusiones Taser. La idea es asociar los cambios con los procesos que los implementan y definir reglas que separen los procesos en procesos «puros&#187. e «inmundo». Se afirma que los resultados son satisfactorios en términos de nivel de automatización, sobrecarga de registro y tiempo de recuperación.

Acerca de puertas traseras y rootkits

Los rootkits, como se sabe, sirven para garantizar que un atacante que ha pirateado un sistema y obtenido privilegios de superusuario pueda seguir teniendo acceso secreto y no autorizado como superusuario. Es decir, un rootkit es a la vez una puerta trasera y un medio para enmascarar actividad maliciosa.

Los rootkits son un tipo de programa troyano y se dividen en rootkits binarios y de nivel de kernel. Los primeros reemplazan las utilidades del sistema, los segundos reemplazan las funciones del kernel que implementan llamadas al sistema. La metodología para clasificar los rootkits e información detallada sobre los mecanismos de su funcionamiento se puede encontrar, por ejemplo, en el artículo [40].

Para identificar rootkits binarios, son suficientes herramientas de monitoreo de integridad (como Tripwire) de archivos clave del sistema.

Con los rootkits a nivel de kernel, la situación es mucho más complicada. Por supuesto, el método de firma también resulta ineficaz en este caso. Si, por ejemplo, se cambia la dirección de la tabla de llamadas del sistema en el controlador de interrupciones correspondiente, ¿qué firma se debe buscar y dónde? Un problema técnico adicional al implementar el escaneo y verificar la integridad de los archivos es la falta de confianza en los resultados de los servicios del sistema.

Si el rootkit se implementa utilizando el mecanismo de carga de módulos del kernel (y este es el método más común en relación con los sistemas Linux), puede intentar, como recomiendan los autores de [41], antes de cargar, realizar un análisis estático binario de los módulos. con elementos de ejecución simbólica para identificar signos de comportamiento malicioso, como escritura en estructuras de control del kernel. Pero, en esencia, se trata de un enfoque antivirus generalizado que combina búsqueda de firmas y heurística, y sus limitaciones son conocidas. Es cierto que los rootkits no deben identificarse entre programas arbitrarios, sino entre módulos que gravitan hacia una determinada estructura interna, característica, por ejemplo, de los controladores de dispositivos, pero los métodos de ofuscación de programas aquí también resultan suficientes para ocultar signos de malicia. . Más precisamente, es posible predecir una «carrera armamentista» entre los medios para identificar signos de comportamiento malicioso y ocultarlos. Según los resultados publicados en el artículo [41], los métodos propuestos e implementados por sus autores permitieron identificar todos los rootkits probados (eran ocho) y no dieron ni un solo falso positivo en casi quinientos módulos legales. . El tiempo de análisis, por regla general, no superó los 10 ms, el máximo fue 420 ms (Pentium IV, 2 GHz, 1 GB de RAM). Entonces, a pesar de los problemas teóricos, cuya presencia y gravedad, por supuesto, los autores conocen, los primeros resultados prácticos resultaron alentadores, aunque los problemas técnicos de integración con el núcleo y garantizar la imposibilidad de eludir el control. El cargador de módulos aún no se ha resuelto.

Los módulos cargables son una importante amenaza a la seguridad de los sistemas operativos monolíticos porque tienen acceso ilimitado al código del núcleo y a las estructuras de datos. Estos módulos representan hasta el 70% del código del núcleo y del 70% al 90% de los errores, cuya vida media es de unos 20 meses (ver [42]). Incluso aparte de los rootkits maliciosos, todavía existen amenazas debido a vulnerabilidades en los controladores de dispositivos escritos apresuradamente. Es recomendable organizar de alguna manera el control de acceso en el kernel para evitar la explotación de vulnerabilidades.

El trabajo [42] desarrolla la dirección marcada en el artículo [41]. Proporciona una especificación de comportamiento aceptable e inaceptable (listas «blancas» y «negras»: direcciones a las que se puede o no navegar, datos a los que se permite o no se puede acceder, áreas donde no se permite ejecutar instrucciones de la máquina, etc. ). El cumplimiento parcial de las especificaciones se puede comprobar de forma estática, el resto se controla de forma dinámica mediante la inserción de un código de verificación. Se afirma que los gastos generales no superan el 23%. Tengamos en cuenta, sin embargo, que el futuro no está en soluciones tan obviamente temporales, sino en sistemas operativos modulares, modelos de seguridad completos para sus componentes y soporte de hardware para implementar políticas de seguridad.

Los rootkits pueden considerarse un tipo de software secreto que incluye, por ejemplo, herramientas para registrar sesiones de usuarios. Se puede ocultar tanto el código ejecutable como los recursos e información asociada que utiliza. Por ejemplo, se puede colocar un código malicioso en la memoria flash de una tarjeta de video y, para ejecutarlo, se puede «inyectar» en un proceso existente. Recursos como archivos y procesos se pueden ocultar al usuario interceptando llamadas al sistema utilizando tecnología rootkit. Hay al menos dos formas de intentar identificar software oculto: 

• intentar detectar mecanismos de ocultación (los enfoques discutidos anteriormente pertenecen a esta categoría);
• intenta obtener información sobre el sistema de varias maneras y encuentra diferencias en los resultados producidos (por ejemplo, compara la salida de los comandos ls y echo * o información de ps y de la tabla de procesos en el kernel , por supuesto, primero llevando los resultados a un formato único).

Una vez que se manipulan los recursos ocultos, se puede esperar que en alguna representación (de bajo nivel) sean visibles. Ésta es la idea principal del enfoque propuesto en [43]. Puede parecer que está mal buscar los síntomas en lugar de la causa raíz de la enfermedad, pero si los síntomas son más fáciles de identificar, ¿por qué no hacerlo? «Escáneres de comparación» se puede iniciar periódicamente en todas las computadoras de una red corporativa; escanear un gigabyte de espacio en disco, según los datos proporcionados en [43], lleva alrededor de medio minuto, por lo que este enfoque parece bastante práctico.

( Recuerde que en el artículo [2] se considera el uso del método «diferencial» para identificar canales secretos).

Por supuesto, es conveniente no sólo impedir la instalación de rootkits o identificarlos rápidamente, sino también automedicar los sistemas comprometidos. Este último es el tema del artículo [44]. La idea es monitorear los cambios en la tabla de llamadas del sistema, la aparición de archivos, procesos e interacciones de red ocultos, y cuando se identifique actividad maliciosa, eliminarla restaurando el estado correcto de la tabla de llamadas del sistema, eliminando archivos ocultos y finalizando procesos ocultos. , bloqueando conexiones de red ocultas . Irónicamente, el prototipo de esta herramienta de protección está implementado en forma de un módulo de kernel cargable y, por lo tanto, puede convertirse en el objetivo de ataques de rootkit, sin mencionar el problema del diagnóstico y tratamiento completo de los sistemas.

La cuestión de quién custodiará a los guardias es una de las eternas e intratables. Si los sistemas protegidos y de protección son los mismos, no hay garantía de que después de un compromiso las medidas de protección funcionen correctamente y el tratamiento que proporcionen sea eficaz y completo. Una forma de aislar los controles de seguridad es la tecnología de máquina virtual mencionada anteriormente. Su uso en el contexto de la identificación de actividades sospechosas se analiza en [45]. Desafortunadamente, en un entorno de red, esta tecnología resulta, por un lado, insuficiente y, por otro, costosa (y los autores de [45], por supuesto, son conscientes de la gravedad de los problemas señalados). ). La desventaja es que, a pesar de la virtualización, el sistema sigue siendo un único nodo de red, sujeto a ataques de disponibilidad y explotación remota de vulnerabilidades del servicio de red. La ineficiencia se debe a la necesidad de cambiar frecuentemente entre contextos de máquinas virtuales y el monitor que las controla.

(Tenga en cuenta entre paréntesis que la tecnología de máquinas virtuales es un medio excelente para implementar de manera efectiva y económicamente justificable cebos y trampas que se cuentan por decenas de miles en varios servidores de hardware, consulte [46].)

(También entre paréntesis como una curiosidad Mencionamos la propuesta de los autores de [47] de aprender métodos de ofuscación de los desarrolladores de rootkits, pero este artículo tiene una excelente barra lateral de descripción general que describe los principales hechos y disposiciones relacionados con los rootkits).

Solo el soporte de hardware promete un gran avance en la seguridad de la información, la implementación de sistemas resistentes a los ataques y capaces de autorrepararse rápida y automáticamente. Lamentablemente, sistemas como el descrito en [48] son ​​una cuestión de futuro, y no muy cercano.

Conclusión

En el artículo [ 2 ] subraya con razón lo importante que es plantear correctamente el problema y considerarlo no de forma aislada, sino en el entorno real. La formulación correcta asociada con la ejecución controlada (restricción) de programas, teniendo en cuenta su semántica, es importante para todo tipo de canales ocultos y secretos.

Al mismo tiempo, desde un punto de vista práctico, el problema de los canales ocultos y secretos no puede considerarse uno de los más acuciantes. Los canales laterales son una amenaza mucho más real para los sistemas integrados. La seguridad de los agentes móviles es un punto débil en la tecnología de Internet/Intranet. Por último, los rootkits y el software secreto en general son una amenaza peligrosa a la que los usuarios comunes y muchos administradores de sistemas no pueden resistir.

Los problemas de seguridad de la información no se pueden resolver únicamente con software. En nuestra opinión, actualmente existe una tendencia hacia la ampliación del soporte de hardware para equipos de protección. Cuándo ese apoyo tomará forma real es cuestión de más de un año. Para que esto tenga una solución real, se necesitan prerrequisitos económicos y legales, y no sólo las alarmantes estadísticas de actividad maliciosa y estimaciones de pérdidas derivadas de ella.

La causa fundamental de los problemas de seguridad de la información debe buscarse en la complejidad de los sistemas modernos. Luchar contra la complejidad significa hacer que los sistemas sean más seguros. Desafortunadamente, el deseo de adelantarse a la competencia y ofrecer un sistema con mayor funcionalidad está obligando a los fabricantes a avanzar en la dirección opuesta. En la actualidad, no existen razones visibles que puedan cambiar esta tendencia. Los integradores de sistemas y los consumidores solo pueden confiar en sí mismos, en su capacidad para elegir la arquitectura más simple y mejor pensada y mantener los sistemas de producción en un estado seguro utilizando medidas técnicas y organizativas, gastando esfuerzo y dinero en repeler lo real, y no lejos. amenazas buscadas.

Literatura

[1] E.E. Timonina — Canales ocultos (revisión). — Jet Info, 2002, 11
[2] A. Galatenko — Acerca de canales ocultos y más. — Jet Info, 2002, 11
[3] R.A. Kemmerer — Un enfoque práctico para identificar canales de almacenamiento y sincronización: veinte años después. — Actas de la 18.ª Conferencia Anual sobre Aplicaciones de Seguridad Informática (ACSAC’02).— IEEE, 2002
[4] E. Tumoian, M. Anikeev — Detección basada en red de canales ocultos pasivos en TCP/IP. — Actas de la Conferencia IEEE sobre redes informáticas locales, 30.º aniversario (LCN’05).— IEEE, 2005
[5] S. Cabuk, C.E. Brodley, C. Escudos — Canales de sincronización IP encubierta: diseño y detección. — Actas de la CCS’04.— ACM, 2004
[6] P.A. Karger, H. Karth — Mayores necesidades de flujo de información para evaluaciones compuestas de alta seguridad. — Actas del Segundo Taller Internacional de Garantía de la Información del IEEE (IWIA’04).— IEEE, 2004
[7] V.B. Betelín, S.G. Bobkov, V.A. Galatenko, A.N. Godunov, A.I. Grunthal, A.G. Kushnirenko, P.N. Osipenko — Análisis de tendencias en el desarrollo de hardware y software y su impacto en la seguridad de la información. — Se sentó. artículos editados por Académico de la Academia de Ciencias de Rusia V.B. Betelina— M.: NIISI RAS, 2004
[8] P. Efstathopoulos, M. Krohn, S. VanDeBogart, C. Frey, D. Ziegler, E. Kohler, D. Mazieres, F. Kaashoek, R. Morris & #8212; Etiquetas y procesos de eventos en el sistema operativo Asbestos. — Actas del SOOP’05.— ACM, 2005
[9] Y. Zhu, R. Bettati — Anonimato vs. Fuga de información en sistemas de anonimato. — Actas de la 25ª Conferencia Internacional IEEE sobre Sistemas de Computación Distribuida (ICDCS’05).— IEEE, 2005
[10] B. Graham, Y. Zhu, X. Fu, R. Bettati — Uso de canales encubiertos para evaluar la eficacia de las medidas de confidencialidad del flujo. — Actas de la 11ª Conferencia Internacional sobre Sistemas Distribuidos y Paralelos de 2005 (ICPADS’05).— IEEE, 2005
[11] Y. Zhu, R. Sivakumar — Retos: Comunicación a través del Silencio en Redes de Sensores Inalámbricos. — Actas del MobiCom’05.— ACM, 2005
[12] R. Browne — Una ley de conservación de la entropía para probar la integridad del análisis de canales encubiertos. — Actas de la CCS’94.— ACM, 1994
[13] S. Weber, P.A. Karger, A. Paradkar — Una taxonomía de fallas de software: herramientas dirigidas a la seguridad. — Actas de la Conferencia sobre Ingeniería de Software para Sistemas Seguros — Creación de Aplicaciones Confiables (SESS’05). — ACM, 2005
[14] J.C. Wray— Un análisis de canales de sincronización encubiertos. — IEEE, 1991
[15] V.B. Betelín, V.A. Galatenko, M.T. Kobzar, A.A. Sidak, I.A. Trifalenkov — Descripción general de los perfiles de protección creados sobre la base de «criterios generales». Requisitos específicos para los servicios de seguridad. — «Seguridad de la tecnología de la información», 2003, 3
[16] K. Loepere — Resolución de canales encubiertos con un sistema seguro de clase B2. — Sistemas de información Honeywell.
[17] J.J. Harmsen, W.A. Perla — Capacidad de Canales Esteganográficos. — Actas del MM-SEC’05.— ACM, 2005
[18] I.S. Moskowitz, L. Chang, R. Newman — La capacidad es el paradigma equivocado. — Actas del taller de 2002 sobre nuevos paradigmas de seguridad.— ACM, 2002
[19] M. Bauer — Nuevos canales encubiertos en HTTP. Agregar navegadores web involuntarios a conjuntos de anonimato. — Actas de la WPES’03.— ACM, 2003
[20] K. Borders, A. Prakash — Web Tap: detección de tráfico web encubierto. — Actas de la CCS’04.— ACM, 2004
[21] D. Slater — Una nota sobre la relación entre los canales encubiertos y la verificación de aplicaciones. — Computer Sciences Corporation, 2005
[22] K. Tiri, I. Verbauwhede — Modelos de simulación de fugas de información de canal lateral. — Actas del DAC 2005.— ACM, 2005
[23] J.R. Rao, P. Rohatgi, H Scerzer, S. Tinguely — Ataques de partición: o cómo clonar rápidamente algunas tarjetas GSM. — Actas del Simposio IEEE sobre seguridad y privacidad de 2002 (S&P’02).— IEEE, 2002
[24] R. Muresan, C. Gebotys — Actual aplanamiento en software y hardware para aplicaciones de seguridad. — Actas del CODES+ISSS’04.— ACM, 2004
[25] V. Roth, U. Pinsdorf, J. Peters — Un motor de búsqueda distribuido basado en contenido basado en código móvil. — Actas del Simposio ACM de 2005 sobre Computación Aplicada (SAC’05).— ACM, 2005
[26] M. Carvalho, T. Cowin, N. Suri, M. Breedy, K. Ford — Uso de agentes móviles como guardias de seguridad itinerantes para probar y mejorar la seguridad de hosts y redes. — Actas del Simposio ACM de 2004 sobre Computación Aplicada (SAC’04).— ACM, 2004
[27] T. Pedireddy, J.M. Vidal— Un prototipo de sistema de seguridad de red multiagente. — Actas de la AAMAS’03.— ACM, 2003
[28] R. Menezes — Autoorganización y Seguridad Informática. — Actas del Simposio ACM de 2005 sobre Computación Aplicada (SAC’05).— ACM, 2005
[29] J. Page, A. Zaslavsky, M. Indrawan — Contrarrestar las vulnerabilidades de seguridad del agente mediante un esquema SENSE extendido. — Actas de la Conferencia Internacional IEEE/WIC/ACM sobre Tecnología de Agentes Inteligentes (IAT’04).— IEEE, 2004
[30] J. Page, A. Zaslavsky, M. Indrawan — Contrarrestar las vulnerabilidades de seguridad en la ejecución del agente mediante un examen de seguridad autoejecutable. — Actas de la AAMAS’04.— ACM, 2004
[31] J. Ameiller, S. Robles, J.A. Ortega-Ruiz — Agentes móviles autoprotegidos. — Actas de la AAMAS’04.— ACM, 2004
[32] M. Christodorescu, S. Jha — Prueba de detectores de malware. — Actas de la ISSTA’04.— ACM, 2004
[33] M. Christodorescu, S. Jha, S.A. Seshia, D. Song, R.E. Bryant — Detección de malware basada en la semántica. — Actas del Simposio IEEE sobre seguridad y privacidad de 2005 (S&P’05).— IEEE, 2005
[34] J.A.M. McHugh, F.P. Deek— Un sistema de incentivos para reducir los ataques de malware. — Comunicaciones de la ACM, 2005, 6
[35] J.V. Harrison— Mejora de la seguridad de la red evitando la ejecución de malware iniciada por el usuario. — Actas de la Conferencia Internacional sobre Codificación y Computación de Tecnologías de la Información (ITCC’05).— IEEE, 2005
[36] A. Bohra, I. Neamtiu, P. Gallard, F. Sultan, L. Iftode — Reparación remota del estado del sistema operativo mediante puertas traseras. — Actas de la Conferencia Internacional sobre Computación Autonómica (ICAC’04).— IEEE, 2004
[37] F. Sultan, A. Bohra, S. Smaldone, Y. Pan, P. Gallard, I. Neamtiu, L. Iftode — Recuperación de sesiones de servicio de Internet debido a fallas del sistema operativo. — IEEE Internet Computing, 2005, marzo/abril
[38] J.B. Grizzard, S. Krasser, H.L. Owen, G.J. Conti, E.R. Dodson — Hacia un enfoque para reparar automáticamente sistemas de red comprometidos. — Actas del Tercer Simposio Internacional IEEE sobre Computación y Aplicaciones en Red (NCA’04).— IEEE, 2004
[39] A. Goel, K. Po, K. Farhadi, Z. Li, E. de Lara — El sistema de recuperación de intrusiones Taser. — Actas de la SOSP’05.— ACM, 2005
[40] J. Levine, J. Grizzard, H. Owen — Una metodología para detectar y caracterizar vulnerabilidades de rootkits a nivel de kernel que implican la redirección de la tabla de llamadas del sistema. — Actas del Segundo Taller Internacional de Garantía de la Información del IEEE (IWIA’04).— IEEE, 2004
[41] C. Kruegel, W. Robesrtson, G. Vigna — Detección de rootkits a nivel de kernel mediante análisis binario. — Actas de la 20.ª Conferencia Anual sobre Aplicaciones de Seguridad Informática (ACSAC’04).— IEEE, 2004
[42] H. Xu, W. Du, S.J. Chapín— Detección de ejecución de código de explotación en módulos de kernel cargables. — Actas de la 20.ª Conferencia Anual sobre Aplicaciones de Seguridad Informática (ACSAC’04).— IEEE, 2004
[43] Y.-M. Wang, D. Beck, B. Vo, R. Roussev, C. Verbowski — Detección de software sigiloso con Strider GhostBuster. — Actas de la Conferencia Internacional de 2005 sobre Sistemas y Redes Confiables (DSN’05).— IEEE, 2005
[44] S. Ring, D. Esler, E. Cole — Mecanismos de autorreparación para problemas del sistema kernel. — Actas de la WOSS’04.— ACM, 2004
[45] M. Laureano, C. Maziero, E. Jamhour — Detección de intrusiones en entornos de máquinas virtuales. — Actas de la 30ª Conferencia EUROMICRO (EUROMICRO’04). — IEEE, 2004
[46] M. Vrable, J. Ma, J. Chen, D. Moore, E. Vandekieft, A.C. Snoeren, G.M. Voelker, S. Savage — Escalabilidad, fidelidad y contención en Potemkin Virtual Honeyfarm. — Actas de la SOSP’05.— ACM, 2005
[47] S. Ring, E. Cole — Aprendiendo una lección de los rootkits sigilosos. — Seguridad y control IEEE Privacidad, 2004, julio/agosto
[48] W. Shi, H.-H.S. Lee, G. Gu, L. Falk — Un sistema de servicio de red autorrecuperable y tolerante a intrusiones que utiliza un multiprocesador de chip de seguridad mejorada. — Actas de la Segunda Conferencia Internacional sobre Computación Autonómica (ICAC’05)— IEEE, 2005