Siguiente: Futuro Arriba: Sistemas de Detección de Intrusiones Previo: Aspectos legales
8 Necesidades, líneas de trabajo
8.1.3 Formato de los datos de auditoría
8.1.3.1 Libro Naranja, Libro Marrón
8.1.3.6 Mecanismos de auditoría
8.5.1 Detectores basados en inteligencia artificial
Capítulo 8
Aunque han aparecido hace ya varios años, los Sistemas de Detección de Intrusiones aún poseen muchos aspectos que necesitan mejorar. Existen grupos de desarrollo cuya labor se centra en algunas de estas características.
En este capítulo se abordan las principales deficiencias de estos sistemas y las líneas de trabajo que se llevan a cabo para solventarlas. [1]
Salvo raras excepciones, ningún sistema suele llegar a ser utilizado ampliamente si no se normaliza o regulariza de alguna forma.
El concepto de normalización está presente en la vida cotidiana. Se pueden adquirir dos paquetes de hojas de diferentes fabricantes que cumplan la misma norma respecto al formato y tamaño. Los aparatos eléctricos de distintas empresas tienen enchufes que se pueden conectar a la red del hogar. Un teléfono móvil comprado en Europa, puede ser utilizado en Estados Unidos, si contempla los requisitos para realizar llamadas en esa región.
Todo esto se debe a la presencia de normas y estándares. Los organismos encargados de crear normas permiten que diferentes empresas adopten la misma solución para un determinado problema.
En lo que respecta a las tecnologías de la información, existen normas que definen normas y estándares para interfaces de comunicación y programación. Los protocolos de comunicación, como IP, TCP, o ICMP son tan sólo algunos ejemplos de este tipo de normas.
Por otra parte, también existen soluciones basadas en traductores, o vehículos de comunicación, con independencia de la plataforma o arquitectura con que se trabaja. Este enfoque también permite el acercamiento y trabajo conjunto de distintas plataformas. El sistema XDR (External Data Representation), por ejemplo, permite la transferencia de datos entre entidades de arquitecturas diferentes, tales como Estaciones SUN, VAX, IBM-PC, o Cray.
La detección de intrusiones no es una excepción al tema de la regularización. Como cualquier otro reto de gran envergadura, la colaboración y acuerdo entre diferentes organismos y empresas se hace cada vez se hace más necesaria. Muchas empresas, ante la ausencia de una solución óptima, han propuesto sus propios productos. Esto provoca situaciones en las que se puede llegar a utilizar cuatro productos diferentes para aprovechar las peculiaridades de cada uno. Afortunadamente existe cierto número de propuestas por parte de diferentes entidades, para evitar este tipo de situaciones.
El "Common Intrusion Detection Framework" (CIDF) es uno de los proyectos más ambiciosos en el ámbito de la normalización de la detección de intrusiones. Fue fundado por Teresa Lunt, para la "Defense Advanced Research Projects Agency" (DARPA). [2]
Es un grupo encargado de crear interfaces que permitan a los desarrolladores de detección de intrusiones compartir sus conocimientos y así poder reutilizar los componentes obtenidos en otros sistemas.
Uno de los resultados de la creación del CIDF, fue la aparición de un grupo de trabajo especializado en la detección de intrusiones por parte de la "Internet Engineering Task Force" (IETF), comentado más adelante.
El "Critical Resource Allocation and Intrusion Response for Survivable Information Systems" (CRISIS), es un grupo de trabajo de similares objetivos a CIDF. Tienen como objetivo unificar los mecanismos de detección, respuesta y control de los sistemas de detección de intrusiones [3]. En concreto, trabajan en dos aspectos:
· Diseñar una arquitectura común para el desarrollo de la detección de intrusiones: En el marco actual, existen numerosas herramientas de detección de intrusiones y de respuesta ante intrusiones. CRISIS intenta proporcionar una plataforma que permita la cooperación entre ellas.
· Proveer mecanismos para la asignación de recursos críticos: Algunos ataques pueden llegar a bloquear al sistema comprometido. Este aspecto se centra en buscar soluciones que permitan a los sistemas de detección utilizar sus recursos para llevar a cabo sin problemas sus tareas de respuesta ante posibles ataques.
Así como la gran mayoría de servidores Web utilizan un formato de registro ya definido en un estándar, los detectores de intrusiones también se pueden beneficiar de este aspecto. No obstante, esta no es una tarea trivial. El formato de los registros de auditoría está muy ligado al sistemas operativo y, por desgracia, existen diferencias sustanciales entre muchos ellos. Este tema es uno de los principales obstáculos con los que se enfrenta la detección de intrusiones en su camino hacia la estandarización.
Una de las propuestas relativas al registro de auditoría está definida en el libro naranja ("Trusted Computer System Evaluation Criteria") [4] y en el libro Marrón ("Tan Book") [5].
En estos documentos se indican con detalle los requisitos que deben cumplir los mecanismos de auditoría.
No obstante, estas especificaciones han provocado numerosas confusiones debido a la falta de exactitud en algunos detalles. Por ejemplo, especifican el contenido con que deben contar los registros, pero no su formato. Por otra parte, indican aquellos eventos que pueden ser auditados, pero no cuáles deben ser auditados.
Esto ha provocado la aparición de sistemas operativos que, a pesar de cumplir con los requisitos descritos por estos documentos, no tienen nada que ver en cuanto a sus mecanismos y registros de auditoría.
Dorothy Denning propone en su documento sobre detección de intrusiones, un formato de registro de auditoría independiente de la plataforma. Desgraciadamente, este formato no aporta suficientes datos sobre la actividad del sistema para proporcionar detecciones de usos indebidos eficaces. [6]
Steve Smaha propuso un formato de registro para sistemas UNIX denominado SVR++ 4, utilizado por las herramientas de detección de los Laboratorios Haystack, como STALKER. Este formato ha sido utilizado por varias empresas para sus productos de detección de intrusiones. [7]
Matt Bishop, de la Universidad de California, Davis, desarrolló un formato de registro de auditoría estándar. Este formato está diseñado para ser independiente del sistema operativo o la plataforma de aplicación. [8]
El "Internet Engineering Task Force" (IETF) creó un grupo de trabajo relativo al área de seguridad, centrado en la detección de intrusiones, denominado "Intrusion Detection Working Group" (IDWG). Algunos de los objetivos de este grupo son:
· Redactar un documento que especifique los requisitos para la comunicación entre IDS, y entre IDS y sistemas de gestión.
· Desarrollar una especificación de un lenguaje de intrusiones común, que describa un formato de datos que cumpla los requisitos.
· Elaborar un documento que describa los mejores protocolos para la comunicación entre IDS, y que indique qué relación tienen con los formatos de los datos.
Han desarrollado un sistema de intercambio de datos, y mecanismos de transporte, que permiten a los detectores de intrusiones contar con un sistema de mensajería específico, que les permite compartir los datos obtenidos entre sí. [9]
Hay que decir que algunos organismos como "Portable Operating System Interface" (POSIX) o X/OPEN han propuesto estándares de auditoría. No obstante, sus propuestas han incluido Interfaces de Programación de Aplicaciones (APIs), o mecanismos de auditoría y no formatos de auditoría.
La integración está muy relacionada con los objetivos del apartado anterior. Consiste en desarrollar un sistema de tal forma que pueda entenderse con el resto de elementos de su entorno.
La integración, en lo que respecta a la detección de intrusiones, implica por ejemplo, poder interpretar correctamente el formato de las fuentes de datos (registros de auditoría del sistema operativo, tráfico heterogéneo de red), así como de contar con métodos que permitan interactuar y compartir recursos con otros mecanismos del sistema.
Este aspecto permite a diferentes sistemas de seguridad coordinar sus esfuerzos y resultados para encontrar y aportar pruebas sobre un determinado ataque o intrusión.
La gestión de la seguridad en redes se puede convertir en una tarea difícil cuando alcanzan gran tamaño. Este es uno de los retos a los que se enfrentan los detectores de intrusiones. La capacidad de proceso y otros recursos de sistema pueden ser insuficientes en determinadas ocasiones. A continuación se describen los dos tipos de elementos más comunes asociados a problemas de escalabilidad: el tiempo y el espacio.
Los problemas de escalabilidad asociados al tiempo se producen cuando un ataque se realiza de forma extremadamente larga. Esto puede provocar que un detector de intrusiones no tenga recursos para almacenar y relacionar todos los indicios de una intrusión. Por ejemplo, si un atacante decidiera escanear un servidor de forma intencionadamente lenta, abriendo un puerto cada hora, o cada día, tardaría mucho en completar su objetivo, pero también podría conseguir que el detector no reconociera el progreso de el ataque.
Estas situaciones se pueden solventar ampliando la franja de tiempo en que el detector debe asociar los eventos sucedidos. Pero esto tiene un límite físico, asociado a los recursos de sistema, como la cantidad de memoria o disco duro disponible.
No obstante, no se pueden añadir sin más recursos del sistema para extender el intervalo de tiempo en que un detector puede relacionar los eventos ocurridos. Un intervalo demasiado amplio podría hacer que el sistema asociara eventos que, por su lejanía en el tiempo, pueden no tener nada que ver, aumentando el número de falsos positivos.
El otro elemento que puede intervenir en la escalabilidad de una infraestructura es el espacio. Esta relacionado con el número de miembros de una red. Cuando dicho número empieza a ser del orden de varios miles, un diseño escalable del sistema de detección de intrusiones puede ayudar mucho en adaptarse a la nueva situación.
Cuando se gestiona una red de gran tamaño, no sólo puede tener muchas máquinas, sino que además, pueden estar repartidas por diferentes zonas geográficas, y tener distintas velocidades de conexión. Esto provoca la aparición de problemas asociados a las diferencias de reloj de cada miembro. Por otra parte, esto también puede dificultar la forma de representar los datos obtenidos.
El sistema de intrusiones utilizado, debe ofrecer facilidades para implementarse de forma estratificada, con una estructura jerárquica en forma de árbol. Los detectores más elementales, pueden dedicarse a monitorizar grupos de máquinas de forma local, y ser controlados y coordinados por una serie de detectores de niveles superiores.
"Graph-Dased Intrusion Detection System" (GrIDS) es un proyecto apoyado por "Defense Advanced Research Projects Agency" (DARPA), desarrollado por la Universidad de California. Es un ejemplo de sistema de detección cuyo diseño permite adaptarse a los problemas de escalabilidad de espacio.
Elabora grafos de actividad de las máquinas de una red, para poder identificar ataques a gran escala. Por esta razón, se suele utilizar especialmente para la detección de ataques en los que está involucrado un importante número de máquinas, como los DDoS (ataques de denegación de servicio distribuida), o ataques provocados por gusanos. También es de gran ayuda en ataques realizados por un escáner de vulnerabilidades, como Nessus, o SATAN.
La estructura de GrIDS permite construir grafos de actividad utilizando los datos obtenidos de múltiples detectores de intrusiones. A nivel general, los resultados del motor de grafos son comparados con una base de patrones de grafos, configurada por el administrador. Esto se hace para distinguir entre aquellos grafos que indican patrones de actividad poco habitual o sospechosa, y grafos de actividad normal.
Los factores descritos en el apartado anterior pueden afectar a la administración de un sistema de detección de intrusiones. Un sistema que no esté bien diseñado, puede ver limitadas sus capacidades de control en una red de importante tamaño.
El número de sensores implicados en la gestión de una gran infraestructura implica contar con métodos especiales para coordinar los datos recibidos de ellos. Carecer de las funciones apropiadas puede hacer imposible la tarea de detectar intrusiones.
Para la gestión de la red, se puede hacer uso de mensajes del Protocolo Simple de Gestión de Red (SNMP). Las últimas versiones de dicho protocolo, ofrecen mecanismos de cifrado para proteger las comunicaciones. No obstante, aún no hay muchos productos de detección de intrusiones que soporten esta opción. Además, el uso de este protocolo puede poner sobre aviso a los posibles atacantes.
Otro de los aspectos clave para la administración de un sistema de detecciones distribuido es el relativo a la centralización los diversos elementos que lo forman, tales como sensores, o motores de análisis. Por un lado, la distribución de estos elementos es vital cuando se trata de monitorizar redes grandes. Hay muchas ventajas de hacer esto, entre las cuales está conseguir más estabilidad, la posibilidad de repartir el trabajo entre varios elementos, o vigilar puntos claves de la red. Sin embargo, esto también implica aspectos negativos como mayor complejidad en la gestión del sistema, o un aumento del tráfico de red originado por las comunicaciones entre los elementos del detector.
Muchos detectores de intrusiones carecen de las suficientes funciones para poder investigar tanto los ataques a un sistema como sus resultados. Este hecho puede dificultar procedimientos como el análisis forense, la recuperación ante una intrusión, o la evaluación de daños.
Un detector de intrusiones debería facilitar mecanismos para ayudar a reconocer la incidencia, aislar los puntos de entrada del intruso, identificar los métodos utilizados para comprometer el sistema, y determinar los efectos derivados de la intrusión en el sistema. Esto no sólo permitiría a un administrador identificar las características del ataque, sino que le serviría para reparar y prevenir el sistema ante futuros ataques de similares características.
El aumento de los delitos informáticos ha provocado la aparición de nuevas leyes que contemplen este tipo de actos. Cada vez son más los sistemas de detección que incluyen soporte para llevar a cabo procedimientos legales.
Algunos ataques, como los de denegación de servicio, tienen como objetivo interrumpir la continuidad de un servicio determinado. Esto puede provocar la caída de un sistema, anulando su gestión. Muchos sistemas de detección de intrusiones intentan solventar este problema, y cuentan con funciones como balanceo de carga, o ajustes de tiempo de ejecución.
Hay una serie de aspectos relacionados con el análisis en los detectores de intrusiones que necesitan especial atención.
La detección de intrusiones mediante técnicas de inteligencia artificial o técnicas no paramétricas es una de las áreas con más posibilidades dentro de estos sistemas de seguridad. Los detectores basados en las técnicas mencionadas, utilizan grandes cantidades de datos de entrenamiento para determinar qué actividad es normal y cuál es anómala. No obstante, el conjunto de datos de entrenamiento debe cumplir una serie de características que no siempre son fáciles de conseguir:
· Debe ser lo suficientemente completo como para reflejar todas las actividades de comportamiento normal del sistema.
· Debe estar libre de ataques. De no ser así, naturalmente, el detector podría etiquetar dichos ataques como comportamientos normales.
· Debe ser lo menos local posible. Esto es, no debe centrarse en aspectos o localizaciones particulares de una infraestructura. De lo contrario, el conjunto de datos podría no ser aplicable a otras zonas de la organización.
Uno de los problemas que han impedido que la detección de anomalías no haya sido ampliamente aceptada por los usuarios, es el relativo a las falsas alarmas. Este problema sigue siendo uno de los retos más importantes para los desarrolladores. Ajustar los motores de detección de anomalías requiere mucho tiempo y un amplio conocimiento sobre el entorno administrado.
Los falsos positivos (errores de Tipo I) tienen lugar cuando el detector cree reconocer una intrusión cuando realmente no lo es. Si se establece una sensibilidad alta para un detector de anomalías, probablemente el número de este tipo de alarmas será importante. Esto puede hacer que un administrador acabe ignorándolas.
Si el número de falsos negativos (errores de Tipo II) es notable, el administrador dejará de confiar en el detector, ante su incapacidad para reconocer ataques reales.
La traducción de las políticas administrativas en políticas de monitorización y de detección es uno de los aspectos que más tiempo suele llevar a la hora de implementar un detector de intrusiones. Esto se debe a las diferencias existentes entre la formulación de ambos grupos de políticas.
Las políticas administrativas indican comportamientos de usuarios, adecuados o no. Normalmente son independientes de la plataforma a implantarse, y están expresadas en términos de objetivos, direcciones, o intenciones de los usuarios, pero no de las máquinas que utilizan.
Las políticas de monitorización y detección descritas para los detectores de intrusiones deben, sin embargo, estar expresadas en términos de eventos que ocurren en un determinado sistema. Por lo tanto, son dependientes de la plataforma.
Algunas herramientas permiten elaborar políticas mediante simples cuestionarios, o aprovechando los resultados emitidos por un escáner de vulnerabilidades. Esta última forma de trabajo es utilizada por ciertos Sistemas de Prevención de Intrusiones, como los Conmutadores Híbridos, mencionados en el capítulo 4. Este tipo de medidas ayudan a integrar las herramientas de seguridad con las funciones de gestión de sistema y de red.
La definición de políticas en el nivel de aplicación mejora la adaptación de interfaces de construcción de políticas a un entorno determinado.
Para que un sistema de detección de intrusiones sea eficaz, configurarlos correctamente no es una medida suficiente. Los mecanismos involucrados en los procesos de detección deben estar provistos de elementos que los protejan en caso de caídas o errores del sistema o ataques.
Cada componente perteneciente al proceso de detección puede dejar de ser fiable. El objetivo es reducir al mínimo las posibilidades de que esto ocurra.
Hay gran variedad de agentes que pueden intervenir en la fase de recogida de información. Esta etapa cuenta por ejemplo con registros de auditoría, agentes, o registros de eventos de sistema.
Algunas situaciones pueden dificultar la obtención de datos, como por ejemplo el uso de comunicaciones cifradas, o un entorno conmutado.
Utilizar protocolos de cifrado (como SSL, SSH o IPSec) anula las posibilidades de interpretación de los datos pertenecientes una comunicación.
Los conmutadores, con sus capacidades de enrutamiento, son otro de los factores que también reducen las posibilidades de monitorización. Esto se puede solventar en parte utilizando conmutadores que tengan unos puertos especiales denominados "spanning ports" (1) (puertos de extensión o abarcadores). Sin embargo la arquitectura de los conmutadores modernos también impide hacer uso de esta opción, ya la suma del ancho de banda producida por varios puertos puede sobrepasar las capacidades de uno solo. Esto una limitación física impuesta por los propios conmutadores.
Otra de las formas de solventar este problema es mediante el uso de "network taps" o cables de red de sólo recepción. En ambos casos, el monitor de red se acopla a un tramo de red, y sólo intercepta el tráfico que pasa por su sección.
Cuando la fuente de datos consiste en algún elemento de un sistema, como sus registros de auditoría, hay que tener en cuenta que se pueden alcanzar posibles situaciones sobrecarga de proceso, ataques, o incluso la recogida de datos falsos, que pueden hacer inservibles los resultados.
La estabilidad y fiabilidad de los elementos que toman parte en la fase de análisis están íntimamente relacionadas con el número de recursos del sistema.
Un motor de análisis que reciba grandes cantidades de información deberá contar con suficiente capacidad de proceso para llevar a cabo su tarea. Este problema se agudiza en los detectores de anomalías. Por otra parte, los detectores de usos indebidos tampoco se escapan a este tipo de problemas. Si el espacio asignado para la base de datos de ataques no es lo suficientemente grande no se podrán estudiar todos los tipos de intrusiones. Además, la aparición de nuevas formas de ataque hace que las bases de datos sean cada vez mayores, así como las necesidades de almacenamiento y tiempo de proceso.
Los detectores de intrusiones de red pueden llegar a descartar paquetes, si no pueden examinar todo el tráfico. Para evitar esta situación, en redes de alta velocidad hay que asegurarse de que los recursos de que dispone el analizador son suficientes.
Otro de los elementos que podrían afectar a la fiabilidad del analizador es que se convirtiera en el objetivo de algún intruso. Existen además, ataques diseñados para sortear las barreras de detección, como los basados en "polymorphic shells" (interfaces de comandos polimórficas). Esta idea, tomada de los programadores de virus, permite cambiar el aspecto del código involucrado en el ataque mediante técnicas de cifrado.
Una de las formas de solventar problemas de sobrecarga y seguridad implica instalar el detector de intrusiones en una máquina separada del objetivo a monitorizar, en casos de detección de "host". Por otra parte, en las situaciones en las que hay mucho tráfico de red, se podría instalar más de un detector basado en red. Dividiendo las tareas de monitorización se reduciría la carga de cada analizador.
La pérdida de estabilidad de los mecanismos de respuesta también puede tener consecuencias graves. A continuación se describen algunas situaciones que lo demuestran.
Si un atacante lograse interceptar o bloquear las alarmas o informes, el sistema de detección entero carecería de valor. Interceptar los mensajes, puede poner al atacante sobre aviso e incluso permitir la modificación del contenido de los mismos. Impedir que las alarmas lleguen al responsable de seguridad anularía toda la efectividad del detector.
Otro escenario distinto es el relativo a las respuestas automáticas. Este tipo de respuestas, comentado en el capítulo 3 "Modelo de funcionamiento", hace que el sistema reaccione de forma activa modificando el entorno. Naturalmente, si este método no cuenta con las apropiadas medidas de seguridad, puede convertirse en un instrumento peligroso en manos de un intruso. Por ejemplo, en el caso de que el detector bloquee automáticamente aquellas direcciones IP relacionadas con un ataque. Sin un intruso logra determinar esto, puede alterar su dirección de origen, y utilizar direcciones que pueden ser fundamentales para el buen funcionamiento de la organización; desde direcciones de clientes, hasta direcciones de la propia red local privada de la infraestructura.
Si los mecanismos de respuesta no proporcionan los requisitos de seguridad necesarios, llegando a ser comprometidos, sus resultados no podrán utilizarse como pruebas en procesos legales.
El uso de mecanismos de encriptación por parte de los sistemas de respuesta es uno de los elementos clave para mejorar significativamente de la fiabilidad de estos sistemas.
La fiabilidad de los elementos nombrados anteriormente depende también de los medios que utilicen para comunicarse.
Los mecanismos que participan en el proceso de detección necesitan comunicarse entre ellos para poder trabajar. Por ejemplo, un detector de máquina puede obtener los registros de sistema a través de una conexión de red mediante el Protocolo Syslog. Otro escenario típico es aquel en que un detector de red debe recibir datos procedentes de los diversos sensores de la infraestructura.
Dado su valor, los enlaces de comunicación deben contar con suficientes medidas de protección para evitar ser vulnerados. Algunos intrusos pueden inhabilitar las líneas de comunicación, o interceptar las comunicaciones.
Una de las formas de mejorar la seguridad y fiabilidad de las comunicaciones consiste en utilizar protocolos de cifrado (SSL, IPSec,...), especialmente cuando se trata de comunicaciones inalámbricas. De esta forma, aunque un atacante intercepte la comunicación, no será capaz de interpretarla, ni podrá alterar su contenido sin que las entidades conectadas se percaten de ello. En estos casos, un atacante puede percatarse de que sus actividades está generando mensajes (aunque estén cifrados) y podría alarmarse. Hay formas de evitar esto, como enviar mensajes en intervalos aleatorios de tiempo.
Otro de los métodos practicados para incrementar las posibilidades de recibir una alarma es el uso de la redundancia. Esta es una solución especialmente recomendable cuando el detector emite alarmas importantes. A veces se establecen varios canales de comunicación redundantes, para ir cambiando de uno a otro de forma aleatoria. En otras ocasiones, la alarma se envía a través de diferentes medios de comunicación, como por ejemplo: un correo electrónico, un mensaje a un teléfono móvil, y la adición de la alarma en el registro de eventos.
Las características de la interfaz ofrecida por el detector de intrusiones, para que el usuario interactúe con él, son otro apartado no menos importante que los ya mencionados.
La interfaz de usuario puede hacer que la tarea de administrar un sistema de detección resulte una sencilla y cómoda, o casi imposible. Esta es una de las razones para no escoger un determinado producto.
Hay muchas formas de representar los datos obtenidos por un detector de intrusiones, y tener deficiencias en este aspecto puede tener graves consecuencias en la detección de posibles ataques. El tipo de detector utilizado es uno de los factores que influyen en la forma de gestionar y visualizar los datos. Un detector de anomalías, por ejemplo, representa sus resultados en forma estadística, de forma distinta que un detector de usos indebidos, que puede mostrar una lista de los ataques identificados.
No todos los usuarios tienen las mismas necesidades de monitorización. Además, una interfaz debería ser lo suficientemente flexible para adaptarse a las necesidades tanto de usuarios noveles como expertos, y aportar información que indique cómo reaccionar ante determinados ataques. Por lo tanto, el hecho de proporcionar amplias capacidades de personalización, mejora las posibilidades de gestión e identificación de ataques.
[1] Bace, R. Intrusion Detection. Macmillan Technical Publishing, 2000.
[2] Common Intrusion Detection Framework (CIDF). [en línea]. Actualizado en septiembre 1999 [consultado en mayo, 2003]. Disponible en <http://www.isi.edu/gost/cidf/>.
[3] Critical Resource Allocation and Intrusion Response for Survivable Information Systems (CRISIS). [en línea] 1997 [consultado en mayo, 2003]. Disponible en <http://www.isi.edu/~brian/crisis/>.
[4] National Computer Security Center. Department of Defense Trusted Computer System Evaluation Criteria. Orange Book, DOD 5200.28-std, December 1985.
[5] National Computer Security Center. A Guide to Understanding audit in Trusted Systems. Versión 2, June 1988.
[7] Smaha, Stephen E. A Common Audit Trail Interchange Format for UNIX. Technical report, Haystack Laboratories, Inc. Austin, Tx, October 1994.
[8] Bishop, Matt. A Standard Audit Log Format. Proceedings of the 1995 National Information Systems Security Conference, Baltimore, MD, October 1995.
(1) Este tipo de puertos se programan para recibir una copia del tráfico dirigido a otros puertos.
Siguiente: Futuro Arriba: Sistemas de Detección de Intrusiones Previo: Aspectos legales
Sistemas de
Detección de Intrusiones, versión 1.01. Julio,
2003.
Diego González Gómez