Lorsque l'on choisi un algorithme de tri ou de recherche de données pour une application normale, on optimise les cas classiques. Néanmoins, pour un IDS le pire scénario est à prendre en considération : un attaquant peut fournir à notre IDS les informations qu'il désire. Si l'IDS est fail-open, il sera capable de passer à travers, et s'il est fail-close, il pourra causer un déni de service sur tout le système protégé.
Illustrons ceci par un exemple. Dans scanlogd, une table de hachage est utilisée pour rechercher l'adresse source. Ceci marche parfaitement pour les cas classiques tant que la table de hachage est suffisamment grande (puisque le nombre d'adresse que l'on conserve est limité). Le temps de recherche moyen est meilleur que celui d'une recherche binaire. Cependant, un attaquant peut choisir son adresse (puisque l'attaque est spoofable) afin de causer un conflit dans la table de hachage, il faudrait donc remplacer cette table par une une recherche linéaire. Tout dépend du nombre d'entrées que l'on souhaite conserver, ce qui peut mener scanlogd à ne pas réussir à obtenir l'information dans les temps. Il prendra aussi plus de temps CPU aux autres processus dans un ISD basé sur une machine hôte tel que scanlogd.
Ce problème peut-être résolu en limitant le nombre de collisions de hachage, et en rejetant les anciennes entrées qui possèdent les mêmes valeurs de hachage lorsque la limite est dépassée. Ceci est acceptable pour les port scans (rappelez-vous que l'on ne peut détecter tout les port scans), mais ce ne serait pas acceptable pour détecter d'autres attaques. Si nous devons détecter d'autres attaques il faudrait changer d'algorithme, et utiliser par exemple une recherche binaire.
Si on utilise un gestionnaire de mémoire (tel que malloc() et free() de la libc), un attaquant peut exploiter ces faiblesses. Un IDS abouti doit possèder ses propres routines de gestion de mémoire (celle le la libc sont diffèrentes d'un système à l'autre), et être très prudent avec ses allocations de mémoire. Pour une application aussi simple que scanlogd, l'allocation dynamique n'a pas besoin d'être utilisé.
Il est probablement important de faire mention des problèmes similaire au niveau du noyau du système d'exploitation. Par exemple, les tables de hachage y sont largements utilisées pour rechercher les connexions actives, les ports en état d'écoute, etc... Il y a d'autres limites qui font que celles-ci ne sont pas vraiment dangereuses, mais ceci demande plus de recherche.