Détermination de l'état par défaut d'une règle fournie par Sourcefire dans une stratégie d'intrusion

Introduction

Cet article explique comment l'équipe de recherche sur les vulnérabilités (VRT) détermine l'état de la règle dans les stratégies d'intrusion par défaut et comment une appliance Sourcefire détermine-t-elle l'état par défaut approprié pour une nouvelle règle.

Détermination de l'état de la règle dans une stratégie par défaut

Chaque règle possède un champ de métadonnées, avec zéro ou plusieurs valeurs de stratégie. Il existe actuellement six valeurs de stratégie possibles :

1. security-ips drop
2. security-ips alert
3. Baisse d'ips équilibré
4. alerte ips symétrique
5. Connectivité-Ips drop
6. connect-ips alert

Si une stratégie IPS est descendante de la stratégie de sécurité et de connectivité Sourcefire, que le périphérique géré est en ligne et qu'une règle a une valeur de stratégie de métadonnées égale à une valeur de suppression des entrées équilibrées, la règle sera définie pour supprimer et générer des événements dans votre stratégie IPS. Si une règle a une valeur de stratégie égale uniquement à security-ips drop, elle sera désactivée dans votre stratégie.

Note: Si plusieurs valeurs de stratégie sont spécifiées pour une règle, par exemple : suppression des entrées de sécurité de la stratégie, suppression des entrées de stratégie équilibrées, elles apparaissent dans les deux stratégies. Si aucune valeur de stratégie n'est spécifiée pour une règle donnée, elle apparaît par défaut dans aucune stratégie.

Si un périphérique géré est défini sur le mode passif et qu'une stratégie est définie sur la suppression, cela n'a aucun effet. Le périphérique génère simplement des alertes. Si un périphérique est en mode en ligne et qu'une valeur de stratégie est définie sur Abandonner, la règle abandonne les paquets par défaut. Si sa valeur de stratégie est définie sur alerte, elle ne génère que des événements, sans perte.

Enfin, dans la plupart des cas, si un paquet est abandonné, une alerte est générée. Ceci est vrai, sauf si la suppression des alertes est configurée indépendamment pour une règle donnée.

Comment Sourcefire détermine-t-il un état par défaut approprié pour une nouvelle règle ?

L'état par défaut d'une règle est basé sur un certain nombre de facteurs. Exemple :

Incidence

Éléments à prendre en compte

Quelle est la probabilité que des tentatives soient faites pour exploiter cette vulnérabilité, et quel pourcentage de nos utilisateurs (clients Sourcefire et communauté Snort en général) est susceptible d'être vulnérable à cette vulnérabilité ?

Éléments à retenir

Une vulnérabilité Internet Explorer avec des attaques connues dans la nature a un impact beaucoup plus important que, par exemple, une fonction de base de données SAP qui peut être utilisée de manière malveillante lorsque les autorisations sont mal configurées, ou une attaque de déni de service complexe dans un module obscur du noyau Linux. VRT émet un jugement d'impact en commençant par le score CVSS d'une vulnérabilité, en le ajustant au besoin avec toute information supplémentaire que nous pourrions posséder. Il s'agit de la mesure la plus importante de toutes, parce que nous allons parfois activer une règle sinon ne serait pas activée / ne serait pas configurée pour chuter si l'impact est assez élevé.

Performances

Éléments à prendre en compte

Attendons-nous que cette règle soit rapide ou lente sur un réseau « moyen » ?

Éléments à retenir

Alors que la vitesse d'une règle dépend entièrement du trafic qu'elle inspecte, ce qui rend les performances difficiles à mesurer, nous avons une idée générale de ce qui constitue un réseau normal, et de la manière dont une règle donnée fonctionne sur ce réseau normal. Nous savons également qu'une règle avec, par exemple, une seule correspondance de contenu qui est relativement longue (6 octets ou plus, généralement) et relativement unique (c.-à-d. « obscureJavaScriptFunction()« , et non "|00 00 00 00|" ou « GET / HTTP/1.1 ») évaluera plus rapidement qu'une règle avec un PCRE complexe, une série de clauses byte_test et/ou byte_saut, etc. Avec cette connaissance, nous pouvons déterminer si une règle sera rapide ou lente et prendre cela en compte.

Confiance

Éléments à prendre en compte

Quelle est la probabilité que cette règle génère des faux positifs ?

Éléments à retenir

Certaines vulnérabilités nécessitent la présence de conditions très spécifiques et facilement détectées pour être exploitées, auquel cas nous pouvons être très confiants que chaque fois que la règle associée se déclenche, une exploitation en direct est en cours. Par exemple, s'il y a un débordement de tampon dans un protocole qui a une chaîne magique unique à une position fixe, puis une longueur spécifiée qui est une distance fixe de cette chaîne magique, nous pouvons être confiants dans notre capacité à trouver la chaîne magique et de la comparer à une valeur connue pour les problèmes. Dans d'autres cas, les problèmes sont beaucoup moins bien définis ; par exemple, certaines attaques d'empoisonnement de cache DNS peuvent être signalées par un nombre anormalement élevé de réponses NXDOMAIN provenant d'un serveur dans un certain temps. Dans ce cas, la simple présence d'une réponse NXDOMAIN n'est pas en soi un indicateur d'un exploit ; c'est la présence d'un très grand nombre de ces réponses en peu de temps qui indique le problème. Étant donné que ce nombre sera différent pour les différents réseaux, le VRT est forcé de choisir une valeur qui devrait fonctionner pour la plupart des réseaux et de libérer cela ; cependant, nous ne pouvons pas être sûrs à 100 % que, lorsque la règle est déclenchée, une activité malveillante réelle se produit.

Enfin, et ce n'est pas le moindre, alors que d'autres facteurs peuvent être considérés de temps à autre comme pertinents, l'impact est roi en fin de compte - s'assurer que nos clients sont protégés contre les menaces qu'ils sont le plus susceptibles de voir dans la nature est notre préoccupation principale.

Historique de révision