Sommaire
Avec la sortie de TAXII 2.1, il est temps de vérifier ce que cette nouvelle version apporte. TAXII, ou Trusted Automated Exchange of Intelligence Information, est un protocole d’échange de renseignements sur HTTPS. Pour plus d’informations sur STIX et TAXII, veuillez consulter notre article de blog sur le sujet : Introduction à STIX et TAXII.
Dans cet article, nous allons parler du principal problème de TAXII 2.0 : la pagination.
TAXII 2.0 : Filtres et pagination
Dans la version 2.0 de TAXII, la pagination a été réalisée en utilisant les en-têtes Range et Content-Range. Lorsqu’un client demande des éléments spécifiques, l’en-tête de la plage doit être spécifié en indiquant la plage nécessaire. Par exemple, si le client veut que les articles se trouvent entre les positions 10 et 49, il a besoin de l’en-tête Range: items 10–49 dans la demande.
Le serveur doit alors répondre à la requête et fournir des informations sur les éléments retournés avec le nombre total d’éléments. Par exemple, Content-Range: éléments 10 à 49/500 où 10 est le premier élément de la réponse, 49 le dernier élément et 500 le nombre total d’éléments disponibles pour cette requête.
Cette façon de naviguer dans les résultats est appelée offset based pagination. Elle est facile à utiliser et à mettre en œuvre sur des ensembles de données relativement petits. Malheureusement, à mesure que nous obtenons de plus en plus de résultats, cette façon de paginer les résultats devient très inefficace. Ce problème provient de deux domaines principaux, le comptage des résultats et l’utilisation d’offsets élevés.
Compter les résultats signifie que la requête effectuée dans la base de données devra passer en revue tous les résultats pour obtenir le nombre exact de résultats correspondant à la requête envoyée par le client.
Cela peut ne pas sembler un problème quand aucun filtre n’est appliqué et l’ensemble de données est petit. Nous devons garder à l’esprit que TAXII offre de nombreuses façons de filtrer les données donnant parfois des requêtes de base de données complexes. De plus, les serveurs TAXII sont souvent utilisés pour partager d’énormes quantités de Cyber Threat Intelligence.
Comment TAXII 2.1 résout les problèmes
TAXII 2.1 remplace la pagination basée sur le décalage dans les en-têtes HTTP pour utiliser une pagination basée sur le curseur.
La requête peut maintenant utiliser deux paramètres de requête :
- limit : pour spécifier le nombre de résultats à obtenir
- next : pour spécifier le curseur à partir duquel récupérer les éléments
La réponse contiendra deux attributs spécifiques dans son corps :
- more : s’il y a plus de résultats à récupérer ou non
- next : le curseur pour obtenir le prochain lot d’éléments
TAXII 2.1 ne précise pas comment le curseur doit être implémenté, il dit :
- Cette valeur est opaque pour le client et représente quelque chose que le serveur sait gérer et traiter.
- Il permet à l’implémentation du serveur de choisir la façon dont ils veulent définir cette valeur en fonction de leur base de données. Par exemple, une entreprise utilisant Elasticsearch pourrait tirer profit de l’API de défilement et utiliser le Scroll id a le paramètre next.
La pagination du curseur à SEKOIA.IO
Chez SEKOIA, notre serveur TAXII se trouve au sommet d’une base de données ArangoDB (voir : Stockage de données Threat Intelligence : facilitez-le avec ArangoDB !). Pour concevoir un curseur efficace, nous avons décidé de créer un curseur personnalisé reposant sur 2 attributs : created et id.
Le curseur est la version base64 de {created}|{id}. Par exemple, un objet avec l’indicateur d’identification indicator–33fe3b22-0201-47cf-85d0-97c02164528d créé le 2017–04–14T13:07:49.812Z donnerait :
MjAxNy0wNC0xNFQxMzowNzo0OS44MTJafGluZGljYXRvci0tMzNmZTNiMjItMDIwMS00N2NmLTg1ZDAtOTdjMDIxNjQ1Mjhk (base64(2017–04–14T13:07:49.812Z|indicator–33fe3b22-0201-47cf-85d0-97c02164528d).
L’inclusion de l’id dans le curseur évite au client de recevoir plusieurs fois le même élément lorsque plusieurs objets ont la même date de création dans la base de données. Lorsque nous récupérons les éléments de la base de données, les résultats sont triés par created ascendant , puis par id ascendant.
Si le client fournit un curseur, nous filtrerons les données pour obtenir seulement les documents correspondant à l’un des critères suivants :
- Éléments ayant la même date que celui donné et un id plus grand
- Objets avec une date plus grande que celle donnée
- Une requête lorsqu’un curseur est fourni ressemblerait à ceci :
Pour améliorer les performances, les requêtes s’appuient sur 3 indices, un pour chacun des champs du curseur et un index composé améliorant le tri. Utiliser cette pagination basée sur un curseur au lieu d’une pagination basée sur une amélioration des performances de plus de 10 fois pour les requêtes qui nécessitaient un grand décalage avant.
Conclusion
Le comité oasis derrière TAXII est à l’écoute des remarques faites par les utilisateurs de TAXII et met à jour sa spécification pour résoudre les problèmes qui se dressent sur la voie d’une bonne adoption de la norme. Taxii 2.1 est un pas dans la bonne direction et chez SEKOIA, nous espérons avoir de plus en plus de clients consommant notre endpoint TAXII 2.1.
Vous trouverez la dernière spécification TAXII à l’adresse suivante : https://docs.oasis-open.org/cti/taxii/v2.1/cs01/taxii-v2.1-cs01.html
Vous pouvez également consulter d’autres articles sur la version FR du Blog :
