IDS en la máquina
Tras leer la sección anterior seguramente habrá quedado claro que un correcto esquema de detección de intrusos basado en red es vital para proteger cualquier sistema; con frecuencia suele ser el punto más importante, que más ataques detecta, y donde se suelen emplazar la mayoría de sistemas de detección que existen instalados en entornos reales hoy en día. No obstante, esta enorme importancia suele degenerar en un error bastante grave: en muchos entornos los responsables de seguridad, a la hora de trabajar con IDSes, se limitan a instalar diversos sensores de detección basados en red en cada segmento a proteger, creyendo que así son capaces de detectar la mayoría de ataques. Y eso suele generar una falsa sensación de seguridad grave, ya que a la hora de lanzar ciertos ataques un pirata puede eludir fácilmente a estos sensores; los sensores de detección en nuestros segmentos de red son importantes, pero no son la panacea. Para comprobarlo, volvamos a nuestro ejemplo anterior, en el que un atacante trata de descubrir vulnerabilidades en nuestros servidores HTTP: si recordamos dónde nos habíamos quedado, el pirata estaba lanzando un escaneador de vulnerabilidades
web contra el puerto 80 de nuestro servidor corporativo; el esquema de detección implantado en el cortafuegos no percibirá nada extraño, pero el sensor ubicado en el segmento donde se encuentra el servidor sin duda verá patrones que denotan un ataque. Por ejemplo, en el momento en que el escáner compruebe la existencia en el servidor de un CGI denominado
phf, SNORT generará una alerta similar a esta:
[
] IDS128 - CVE-1999-0067 - CGI phf attempt []
03/10-03:29:59.834996 192.168.0.3:1032 -> 192.168.0.1:80
TCP TTL:56 TOS:0x0 ID:5040 IpLen:20 DgmLen:58 DF
*AP* Seq: 0x91FA846 Ack: 0x5AD9A72 Win: 0x7D78 TcpLen: 20
Como veremos en el punto siguiente, es posible que al generar este aviso, el propio sensor decida lanzar una respuesta automática contra la dirección atacante (por ejemplo, bloquearla en el cortafuegos corporativo). Pero SNORT trabaja basándose en su base de datos de patrones de ataques; en dicha base de datos habrá una regla como la siguiente:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-CGI phf access";\
flags: A+; content:"/phf";flags: A+; nocase; reference:arachnids,128; \
reference:cve,CVE-1999-0067; )
A grandes rasgos, esta regla viene a decir que cuando el sensor detecte una petición al puerto 80 de nuestro servidor
web en cuyo contenido se encuentre la cadena
`/phf' levante la alerta correspondiente; de esta forma, cuando el atacante solicite el archivo
/cgi-bin/phf del servidor, SNORT `verá' dicha cadena en la petición y generará una alarma. >Pero qué sucede si el atacante solicita ese mismo fichero pero utilizando una petición `ofuscada', formada por los códigos ASCII de cada carácter? Es decir, si en lugar de lanzar una petición como
`GET /cgi-bin/phf' hace una similar a
`GET %2f%63%67%69%2d%62%69%6e%2f%70%68%66'. La respuesta es sencilla: la petición anterior se `decodifica' en el propio servidor
web, o como mucho en un
proxy intermedio. Algunos detectores de intrusos, como RealSecure, son en teoría capaces de procesar este tipo de tráfico y analizarlo normalmente en busca de patrones sospechosos, pero otros muchos (SNORT en este caso) no; así, estos últimos no verán en ningún momento la cadena
`/phf' circulando por la red, y por tanto no generarán ninguna alarma. Parece entonces evidente que es necesario un nivel adicional en nuestro esquema de detección: justamente el compuesto por los sistemas basados en la propia máquina a proteger.
Antes hemos hablado de los tres modelos básicos de IDSes basados en máquina: verificadores de integridad, analizadores de registros y
honeypots. Parece claro que un verificador de integridad en nuestro caso no va a resultar muy útil para detectar a ese atacante (esto no significa que no se trate de modelos necesarios y útiles en otras muchas situaciones). Tendremos por tanto que recurrir a analizadores de
logs o a tarros de miel instalados en la máquina. Si optamos por los primeros, es sencillo construir un
shellscript que procese los archivos generados por el servidor
web - en nuestro caso, aunque igualmente sencillo que procesar registros del sistema o de otras aplicaciones - en busca de patrones que puedan denotar un ataque, como el acceso a determinados archivos bajo el
DocumentRoot. Si analizamos cualquier
CGI Scanner nos podremos hacer una idea de a qué patrones debemos estar atentos: por ejemplo, intentos de acceso a CGIs como
phf o
printenv, a archivos
passwd, a ficheros fuera del
DocumentRoot, etc.
Aunque analizar los registros generados por una aplicación en busca de ciertos patrones sospechosos es una tarea trivial, no lo es tanto el integrar ese análisis en un esquema de detección de intrusos. Seguramente procesar la salida de un
`tail -f' del archivo de
log correspondiente, enviando un correo electrónico al responsable de seguridad cuando se detecte una entrada sospechosa es fácil, pero por poner un simple ejemplo, >qué sucede cuando la máquina se reinicia o el fichero de registros se rota? >Es necesario volver a entrar y lanzar de nuevo la orden correspondiente para analizar los
logs? Seguramente alguien planteará que se puede planificar una tarea para que periódicamente compruebe que se está procesando el archivo, y lance el análisis en caso de que no sea así...>pero hasta qué punto es esto cómodo? >qué sucede con las entradas duplicadas? >y con los registros perdidos que no se llegan a procesar? Evidentemente, no todo es tan sencillo como el simple
`tail -f' anterior.
El análisis de registros generados por el sistema o por ciertas aplicaciones suele ser una excelente fuente de información de cara a la detección de actividades sospechosas en nuestros entornos, pero no es habitual aplicar dicho análisis en un esquema de respuesta automática ante ataques. Es mucho más común automatizar la revisión de
logs para que periódicamente (por ejemplo, cada noche) se analicen esos registros y se envíe un mensaje de alerta por correo electrónico a los responsables de seguridad en caso de que algo anormal se detecte; evidentemente no es un modelo que trabaje en tiempo real, pero no por ello deja de ser un esquema útil en la detección de intrusos; el único problema que se presenta a la hora de realizar el análisis suele ser la decisión de qué patrones buscar en los registros, algo que depende por completo del tipo de
log que estemos analizando.
Aparte de los sistemas de detección basados en el análisis de registros, otro esquema que podemos - y debemos - implantar en cada máquina son los
honeypots o tarros de miel, mecanismo que nos ha de permitir detectar ciertos ataques aunque el resto de sensores de nuestro modelo falle. Como antes hemos comentado, hay diferentes modelos de tarros de miel, desde los simples detectores de pruebas hasta los complejos sistemas dedicados por completo a esta tarea; para detectar ataques rutinarios estos últimos suelen ser algo excesivo e incluso en ocasiones difícil no sólo desde un punto de vista estrictamente técnico, ya que no siempre podemos dedicar una máquina entera a `engañar' atacantes, aparte del tiempo necesario para configurarla correctamente, actualizarla, revisar sus registros, etc. Esquemas teóricamente más simples pueden incluso resultar más efectivos en la práctica.
En nuestro caso no vamos a complicarnos mucho la existencia; si recordamos a nuestro atacante, estaba lanzando un escaneo de vulnerabilidades contra nuestro servidor
web; nuestro IDS basado en red detectará el ataque y en consecuencia dará la voz de alarma y, adicionalmente, ejecutará una respuesta automática contra el pirata, bloqueándolo en el cortafuegos corporativo. Ese atacante ya puede más que sospechar que tenemos un detector de intrusos basado en red que le impide completar su escaneo, ya que en el momento que se detecta tráfico sospechoso bloquea por completo a la dirección origen; por tanto, un paso lógico para él es intentar un análisis de vulnerabilidades `camuflado', bien mediante una simple codificación de peticiones bien mediante un complejo
stealth scan. De nuevo, buscará la existencia de CGIs vulnerables, como
/cgi-bin/phf o
/cgi-bin/printenv, y en este caso SNORT será incapaz de detectar el ataque. Pero forzosamente a nuestro servidor
web han de llegar estas peticiones, por lo que >qué mejor forma de detectar al pirata que en la propia máquina? No tenemos más que situar en el directorio donde se ubican nuestros CGIs un programa que nos informe si alguien intenta acceder a él, tan simple como el siguiente
shellscript:
anita:~# cat /web/cgi-bin/phf
#!/bin/sh
/bin/echo "Pirata desde "$REMOTE_ADDR|mailx -s "Ataque PHF" root
/bin/echo "Content-type: text/html"
/bin/echo
/bin/echo "<HTML><CENTER>Sonrie a la camara oculta...</CENTER></HTML>"
anita:~#
Evidentemente la `decepción' del sistema anterior en un atacante durará unos pocos segundos, ya que es inmediato para éste detectar que se trata de una simple trampa; si queremos algo más elaborado, tampoco es difícil conseguirlo: podemos simular el comportamiento de diferentes CGIs con vulnerabilidades conocidas de una forma muy sencilla. Por ejemplo, existen diferentes `imitaciones' de CGIs vulnerables que aparentan un problema de seguridad pero que en realidad se trata de sistemas de decepción más o menos eficaces; en
http://www.eng.auburn.edu/users/rayh/software/phf.html## podemos encontrar una versión muy interesante del CGI phf
, capaz de simular los ataques más habituales contra el programa original de una forma bastante creíble - aunque no perfecta -. Además en este caso el código en Perl es fácilmente modificable, con lo que podemos desde adecuarlo a nuestros sistemas hasta mejorar su simulación; si lo hacemos, es muy posible que mantengamos `entretenidos' incluso a piratas con conocimientos por encima de la media de atacantes (esto lo digo por experiencia). También podemos construirnos nuestros propios CGIs que aparenten ser vulnerables, en muchos casos simplemente con unos conocimientos básicos de programación en shell o en Perl; por ejemplo, el código siguiente simula el CGI printenv
, proporcionando información falsa sobre el sistema que parece útil para un atacante, y avisando por correo electrónico a los responsables de seguridad del sistema cuando alguien accede al programa:
anita:/# cat /web/cgi-bin/printenv
#!/usr/bin/perl
$SECUREADDRESS="root";
$mailprog = '/usr/lib/sendmail';
print "Content-type: text/html\n\n";
print "SERVER_SOFTWARE = Apache/1.3.12<br>";
print "GATEWAY_INTERFACE = CGI/1.2<br>";
print "DOCUMENT_ROOT = /usr/local/httpd/htdocs<br>";
print "REMOTE_ADDR = $ENV{'REMOTE_ADDR'}<br>";
print "SERVER_PROTOCOL = $ENV{'SERVER_PROTOCOL'}<br>";
print "SERVER_SIGNATURE = <br><i>Apache/1.3.9 Server at \
$ENV{'SERVER_NAME'}</i><br><br>";
print "REQUEST_METHOD = GET<br>";
print "QUERY_STRING = $ENV{'QUERY_STRING'}<br>";
print "HTTP_USER_AGENT = $ENV{'HTTP_USER_AGENT'}<br>";
print "PATH = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:\
/usr/local/bin<br>";
print "HTTP_ACCEPT = image/gif, image/x-xbitmap, image/jpeg<br>";
print "HTTP_CONNECTION = Keep-Alive<br>";
print "REMOTE_PORT = $ENV{'REMOTE_PORT'}<br>";
print "SERVER_ADDR = $ENV{'SERVER_ADDR'}<br>";
print "HTTP_ACCEPT_LANGUAGE = en<br>";
print "SCRIPT_NAME = /cgi-bin/printenv<br>";
print "HTTP_ACCEPT_ENCODING = gzip<br>";
print "SCRIPT_FILENAME = /usr/local/httpd/cgi-bin/printenv<br>";
print "SERVER_NAME = $ENV{'SERVER_NAME'}<br>";
print "REQUEST_URI = /cgi-bin/printenv<br>";
print "HTTP_ACCEPT_CHARSET = iso-8859-1, utf-8<br>";
print "SERVER_PORT = $ENV{'SERVER_PORT'}<br>";
print "HTTP_HOST = $ENV{'HTTP_HOST'}<br>";
print "SERVER_ADMIN = webmaster<br>";
# Enviamos correo
open (MAIL, "|$mailprog $SECUREADDRESS") or die "Can't open $mailprog!\n";
print MAIL "To: $SECUREADDRESS\n";
print MAIL "From: PRINTENV Watcher <$SECUREADDRESS>\n";
print MAIL "Subject: [/CGI-BIN/PRINTENV] $ENV{'REMOTE_HOST'} $action\n\n";
print MAIL "\n";
print MAIL "
\n";
print MAIL "Remote host: $ENV{'REMOTE_ADDR'}\n";
print MAIL "Server: $ENV{'SERVER_NAME'}\n";
print MAIL "Remote IP address: $ENV{'REMOTE_ADDR'}\n";
print MAIL "HTTP Referer: $ENV{'HTTP_REFERER'}\n";
print MAIL "Query String: $ENV{'QUERY_STRING'}\n";
print MAIL "\n
\n";
close(MAIL);
exit;
anita:/#
Estrategias de respuesta
Una pregunta importante que nos habíamos realizado con respecto a nuestro esquema de deteccción de intrusos (en concreto cuando hablábamos de SNORT) era qué hacer con la información obtenida del mismo; como siempre, tenemos varias posibilidades. Por un lado, podemos procesarla manualmente de forma periódica (por ejemplo cada mañana) y en función de los datos que nuestros sensores hayan recogido tomar una determinada acción: bloquear las direcciones atacantes en el firewall corporativo, enviar un correo de queja a los responsables de dichas direcciones (por desgracia esto no suele resultar muy útil), realizar informes para nuestros superiores, o simplemente no hacer nada. Dependerá casi por completo de la política de seguridad que sigamos o que tengamos que seguir.
Mucho más interesante que cualquiera de estas respuestas manuales es que el propio sensor sea capaz de generar respuestas automáticas ante lo que él considere un intento de ataque. Si elegimos esta opción, lo más habitual suele ser un bloqueo total de la dirección atacante en nuestro cortafuegos, unida a una notificación de cualquier tipo (SMS, e-mail...) a los responsables de seguridad; es siempre recomendable efectuar esta notificación (si no en tiempo real, si al menos registrando las medidas tomadas contra una determinada dirección en un log) por motivos evidentes: si bloqueamos completamente el acceso de alguien hacia nuestros sistemas, debemos pararnos a pensar que es posible que se trate de un usuario autorizado que en ningún momento atacaba nuestras máquinas, a pesar de que el sensor que hemos instalado opine lo contrario. No importa lo seguros que estemos de lo que hacemos ni de las veces que hayamos revisado nuestra base de datos de patrones: nunca podemos garantizar por completo que lo que nuestro IDS detecta como un ataque realmente lo sea.
Un correcto esquema de respuesta automática (asumimos que vamos a bloquear la dirección que presuntamente nos ataca) debería contemplar al menos los siguientes puntos:
- >Qué probabilidad hay de que el ataque detectado sea realmente un falso positivo?
No todos los ataques que un sensor detecta tienen la misma probabilidad de serlo realmente: por ejemplo, alguien que busca en nuestros servidores web un CGI denominado
phf
(un programa que se encuentra en versiones antiguas - muy antiguas - de Apache, y que presenta graves problemas de seguridad) casi con toda probabilidad trata de atacar nuestros sistemas; en cambio, una alarma generada porque el sensor detecta un paquete ICMP de formato sospechoso no tiene por qué representar (y seguramente no lo hará) un verdadero ataque. Es necesario, o cuanto menos recomendable, asignar un peso específico a cada alarma generada en el sensor, y actuar sólo en el caso de que detectemos un ataque claro: o bien un evento que denote muy claramente un intento de intrusión, o bien varios menos sospechosos, pero cuya cantidad nos indique que no se trata de falsos positivos.
>Debemos contemplar direcciones `protegidas'?
Otro punto a tener en cuenta antes de lanzar una respuesta automática contra un potencial atacante es su origen; si se trata de una dirección externa, seguramente la respuesta será adecuada, pero si se trata de una interna a nuestra red (o equivalentemente, de direcciones de empresas colaboradoras, aunque sean externas) la cosa no está tan clara. Debemos plantearnos que quizás estamos bloqueando el acceso a alguien a quien, por los motivos que sea, no deberíamos habérselo bloqueado. Aunque se trate de cuestiones mas políticas que técnicas, es muy probable que en nuestro IDS debamos tener claro un conjunto de direcciones contra las que no se va actuar; si desde ellas se detecta actividad sospechosa, podemos preparar un mecanismo que alerte a los responsables de seguridad y, bajo la supervisión de un humano, tomar las acciones que consideremos oportunas.
>Hay un límite al número de respuestas por unidad de tiempo?
Seguramente la respuesta inmediata a esta pregunta sería `no'; a fin de cuentas, si me atacan diez direcciones diferentes en menos de un minuto, >qué hay de malo en actuar contra todas, bloqueándolas? En principio esta sería la forma correcta de actuar, pero debemos pararnos a pensar en lo que es normal y lo que no lo es en nuestro entorno de trabajo. >Es realmente habitual que suframos ataques masivos y simultáneos desde diferentes direcciones de Internet? Dependiendo de nuestro entorno, se puede considerar una casualidad que dos o tres máquinas diferentes decidan atacarnos al mismo tiempo; pero sin duda más de este número resulta cuanto menos sospechoso. Un pirata puede simular ataques desde diferentes hosts de una forma más o menos sencilla y si nos limitamos a bloquear direcciones (o redes completas), es fácil que nosotros mismos causemos una importante negación de servicio contra potenciales usuarios legítimos (por ejemplo, simples visitantes de nuestras páginas web o usuarios de correo), lo cual puede representar un ataque a nuestra seguridad más importante que el que causaría ese mismo pirata si simplemente le permitiéramos escanear nuestras máquinas. Si nuestro sensor lanza demasiadas respuestas automáticas en un periodo de tiempo pequeño, el propio sistema debe encargarse de avisar a una persona que se ocupe de verificar que todo es normal.
Teniendo en cuenta los puntos anteriores (y seguramente otros), debemos diseñar un esquema de respuestas automáticas adecuado. Un pseudoalgoritmo del funcionamiento de nuestro esquema podría ser el siguiente:
ESTADO: {Detecci'on ataque}
SI umbral de respuestas superado: FIN
SI NO
Comprobaci'on IP atacante
SI es IP protegida: FIN
SI NO
Ponderaci'on hist'orica de gravedad
SI umbral de gravedad superado:
ACTUAR
SI NO
REGISTRAR
FSI
FSI
FSI
Como vemos, al detectar un ataque desde determinada dirección, el modelo comprueba que no se ha superado el número de respuestas máximo por unidad de tiempo (por ejemplo, que no se ha bloqueado ya un número determinado de direcciones en las últimas 24 horas); si este umbral ha sido sobrepasado no actuaremos de ninguna forma automática, principalmente para no causar importantes negaciones de servicio, pero si no lo ha sido, se verifica que la dirección IP contra la que previsiblemente se actuará no corresponde a una de nuestras 'protegidas', por ejemplo a una máquina de la red corporativa: si es así se finaliza. Este `finalizar' no implica ni mucho menos que el ataque no haya sido detectado y se haya guardado un log del mismo, simplemente que para evitar problemas mayores no actuamos en tiempo real contra la máquina: si corresponde al grupo de `protegidas' es porque tenemos cierta confianza - o cierto control - sobre la misma, por lo que un operador puede preocuparse más tarde de investigar la alerta. Si se trata de una dirección no controlada ponderamos la gravedad del ataque: un ataque con poca posibilidad de ser un falso positivo tendrá un peso elevado, mientras que uno que pueda ser una falsa alarma tendrá un peso bajo; aún así, diferentes ataques de poco peso pueden llegar a sobrepasar nuestro límite si se repiten en un intervalo de tiempo pequeño. Es importante recalcar el `diferentes', ya que si la alarma que se genera es todo el rato la misma debemos plantearnos algo: >es posible que un proceso que se ejecuta periódicamente y que no se trata de un ataque esté todo el rato levantando una falsa misma alarma? La respuesta es sí, y evidentemente no debemos bloquearlo sin más; seguramente es más recomendable revisar nuestra base de datos de patrones de ataques para ver por qué se puede estar generando contínuamente dicha alarma.
Por último, si nuestro umbral no se ha superado debemos registrar el ataque, su peso y la hora en que se produjo para poder hacer ponderaciones históricas ante más alarmas generadas desde la misma dirección, y si se ha superado el esquema debe efectuar la respuesta automática: bloquear al atacante en el cortafuegos, enviar un correo electrónico al responsable de seguridad, etc. Debemos pensar que para llegar a este último punto, tenemos que estar bastante seguros de que realmente hemos detectado a un pirata: no podemos permitirnos el efectuar respuestas automáticas ante cualquier patrón que nos parezca sospechoso sin saber realmente - o con una probabilidad alta - que se trata de algo hostil a nuestros sistemas.
Antes de finalizar este punto, es necesario que volver a insistir una vez más en algo que ya hemos comentado: es muy recomendable que ante cada respuesta se genere un aviso que pueda ser validado por un administrador de sistemas o por responsables de seguridad, mejor si es en tiempo real; por muy seguros que estemos del correcto funcionamiento de nuestro detector de intrusos, nadie nos garantiza que no nos podamos encontrar ante comportamientos inesperados o indebidos, y con toda certeza es más fácil para una persona que para una máquina darse cuenta de un error y subsanarlo.
Ampliación del esquema
Las ideas que acabamos de comentar pueden resultar más o menos interesantes, pero presentan varios problemas importantes que es necesario comentar. El primero y más importante es la descentralización del esquema: tenemos implantadas varias aproximaciones a la detección de intrusos, pero hasta ahora no hemos hablado de la relación entre ellas; cada uno de los modelos de detección y/o respuesta de los que hemos tratado puede actuar de forma independiente sin muchos problemas, pero en los entornos actuales esto es cada vez menos habitual. Hoy en día, lo normal es encontrarse arquitecturas de red segmentadas, con sensores en cada segmento tanto a nivel de red como de host, así como uno o varios cortafuegos corporativos en los que también se lleva a cabo detección de intrusos y respuesta automática. Está claro que tener elementos independientes no es la aproximación más adecuada, por lo que necesitamos un esquema capaz de unificar los ataques detectados, por ejemplo para correlar eventos y lanzar únicamente una respuesta automática ante un mismo ataque, aunque se detecte simultáneamente en diferentes sensores; sin ser tan ambiciosos, la centralización en una única consola puede ser necesaria para algo tan simple como generar estadísticas mensuales acerca del número de ataques contra nuestro entorno de trabajo: si un mismo ataque se detecta en varios sensores, >cómo contabilizarlo? >cómo saber si se trata del mismo intruso o de varios? >quién de todos decide lanzar una respuesta automática?...
Para tratar de solucionar este importante problema, hace unos años se definió el grupo de trabajo IDWG (Intrusion Detection Exchange Format Working Group), englobado dentro del IETF (Internet Engineering Task Force); su propósito es obvio: tratar de definir estándares para el intercambio de información entre los diferentes elementos de un sistema de detección de intrusos y respuesta automática, tanto a nivel de formato de datos como de procedimientos de intercambio. Mediante esta aproximación se facilita enormemente tanto la integración de sistemas, ya que de lo único que nos debemos preocupar es que todos los elementos (sensores, consolas, elementos de respuesta...) sean capaces de `hablar' el estándar, como la escalabilidad: añadir a un entorno de detección distribuido un nuevo IDS, comercial o desarrollo propio, es mucho más sencillo, ya que casi sólo hemos de conseguir que el nuevo elemento utilice los formatos estándar definidos por el IDWG.
Hasta la fecha, el grupo de trabajo ha publicado cuatro borradores que cubren los requisitos (de alto nivel) para las comunicaciones dentro del sistema de detección de intrusos, el modelo de datos para representar la información relevante para los IDSes - incluyendo una implementación en XML -, el protocolo BEEP (Blocks Extensible Exchange Protocol) aplicado a la detección de intrusos, y finalmente el protocolo IDXP (Intrusion Detection eXchange Protocol) para intercambio de información entre entidades de un sistema distribuido de detección de intrusos. Sin duda el primero y el último son especialmente importantes, ya que constituyen la base del sistema de intercambio de datos entre los diferentes elementos del entorno: marcan el `lenguaje' que antes decíamos que tenían que saber hablar todas y cada una de las entidades del sistema distribuido.
Desde http://www.ietf.org/html.charters/idwg-charter.html## pueden consultarse los trabajos del IDWG; se trata de un grupo activo, que realiza contínuamente revisiones y mejoras de sus borradores para tratar de convertirlos en un estándar real. Si algún día esto es así, habremos dado un paso muy importante en el diseño, implantación y gestión de sistemas distribuidos de detección de intrusos; lamentablemente, muchos de los productos actuales no parecen tener mucho interés en acercarse al estándar (quizás por miedo a perder cota de mercado). La integración de algunos sistemas (como SNORT) es bastante inmediata, pero en cambio la de otros - especialmente productos comerciales, altamente cerrados - no lo es tanto; mientras esto no cambie, es difícil que se consiga implantar el estándar, así que ójala estos fabricantes se den cuenta de que su adaptación a los borradores del IDWG produce sin duda más beneficios que daños.
