OpenCTI (6.0.10+) dans les environnements isolés (Air gap/diode)
La Cyber Threat Intelligence est faite pour être utilisée partout, et ce mot ne signifie pas seulement "dans tous les pays du monde". Il signifie également dans des réseaux "connectés" ou "déconnectés". Les données ingérées dans OpenCTI peuvent être très différentes selon l'usage des organisations et donc la sécurité qui y est associée. Lorsque la sécurité est une priorité, il peut être intéressant d'avoir un déploiement dans un environnement "air gap".
Air gap
Commençons par une définition simple de ce terme.
Un air gap, air wall, air gapping ou réseau déconnecté est une mesure de sécurité réseau appliquée à un ou plusieurs ordinateurs pour garantir qu'un réseau informatique sécurisé est physiquement isolé des réseaux non sécurisés, tels qu'Internet public ou un réseau local non sécurisé. https://en.wikipedia.org/wiki/Air_gap_(networking)
Sur la base de cette définition, il est facile de comprendre que cette limitation nécessitera d'adapter la façon dont la plateforme est déployée et gérée. Jusqu'à présent, cette limitation n'était pas nativement adressée par la plateforme et nécessitait des efforts supplémentaires de la part des organisations. Comme une des missions d'OpenCTI est d'être déployé partout de manière simple, nous avons décidé de travailler sur ce sujet pour publier une manière native de réaliser ce déploiement "air gap".
Principe d'architecture
Cet article vise à décrire une infrastructure air gap simple entre deux plateformes. Dans cette architecture, nous aurons une plateforme connectée à internet, appelée "zone internet", et une plateforme isolée, appelée "zone restreinte".
Dans la "zone internet", la plateforme sera responsable de la récupération des informations CTI sur les sources internet (#connecteurs externes vers fichiers). Aucune donnée ne sera écrite dans cette plateforme, seulement la gestion des connecteurs.
Dans la "zone restreinte", la plateforme sera responsable de l'ingestion des données récupérées depuis la "zone internet" (#connecteur diode-import vers OpenCTI) et de les rendre disponibles dans l'interface utilisateur d'OpenCTI.
Les données seront transférées de la "zone internet" vers la "zone restreinte" via des transferts de fichiers de manière unidirectionnelle (diode).
Connecteurs externes vers fichiers
Pour réaliser cela, nous avons dû modifier le framework python pour permettre aux connecteurs externes d'écrire les données dans des fichiers si nécessaire. Actuellement, les données sont envoyées uniquement vers le RabbitMQ d'OpenCTI, mais avec cette nouvelle option, il sera possible d'écrire des bundles spécifiques dans des fichiers en plus de l'envoi vers la file d'attente si nécessaire.
Connecteurs supportés
Pour être supporté dans ce mode, le connecteur doit être de type "external-import" et construire des bundles STIX pour l'ingestion au lieu d'utiliser l'API pour ingérer les données. La majorité des connecteurs de ce type doivent être compatibles, mais si vous en trouvez un que vous souhaitez utiliser et qui n'est pas supporté, n'hésitez pas à rejoindre la communauté slack et à créer un ticket Github.
À l'exception du connecteur diode-import qui sera utilisé pour réimporter les données
Configuration du connecteur
Pour les connecteurs compatibles, de nouvelles options sont disponibles dans la section connecteur. Pour faciliter la vie des administrateurs, il est également possible de définir un nombre maximum de jours de rétention pour éviter l'explosion des fichiers dans ce répertoire.
Copied!
1connector:2 send_to_queue: True3 send_to_directory: True4 send_to_directory_path: "/air_gap"5 send_to_directory_retention: 7
Format de fichier de données
Les fichiers exportés vers ce répertoire ne sont pas seulement des bundles STIX. Afin de pouvoir simuler les comportements et utilisateurs des connecteurs originaux, le fichier doit contenir plus d'informations que seulement les informations STIX.
Copied!
1{2 "bundle_type": "DIRECTORY_BUNDLE",3 "applicant_id": "<ORIGINAL_USER_ID>",4 "connector": { Original connector information },5 "entities_types": "<LIST_CONTEXT_ENTITY_TYPES>",6 "bundle": { STIX bundle },7 "update": "<UPDATE_MODE>"8}
Transfert de fichiers
Le transfert de fichiers n'est pas directement géré par OpenCTI entre les deux zones. Nous devons utiliser un outil dédié pour le faire. De nombreuses solutions existent, certaines natives sous Linux comme rsync ou des logiciels spécifiques sous licence (comme Axway MFT).
Connecteur diode-import vers OpenCTI
L'étape suivante après le transfert des fichiers de données est d'intégrer les données dans la plateforme OpenCTI de la "zone restreinte". Pour ce faire, le seul connecteur qui doit être déployé est le connecteur diode-import.
Ce connecteur a un comportement très spécifique pour réintégrer les données. Comme plusieurs connecteurs peuvent envoyer les données via des fichiers, nous devons reconstruire les connecteurs initiaux dans l'OpenCTI restreint et allouer tous les messages dans les files d'attente correspondantes pour simuler l'activité d'origine. Comme OpenCTI utilise également un utilisateur spécifique pour intégrer les données, il sera nécessaire de mapper "l'utilisateur de la zone interne" à "l'utilisateur de la zone restreinte" pour créer l'historique de modifications correct.
Copied!
1diode_bundle_import:2 get_from_directory_path: '/restricted_zone'3 get_from_directory_retention: 74 applicant_mappings: "<PUBLIC_USER>:<RESTRICTED_USER>,..."
Vue d'ensemble
Pour avoir une vue d'ensemble du système, n'hésitez pas à ouvrir cette représentation Figma.

Conclusion
L'introduction d'une manière native de gérer les environnements air gap aidera les organisations à sécuriser leurs données CTI sans développer/créer de nombreuses intégrations spécifiques.
Bien sûr, cette première implémentation sera améliorée à l'avenir et tous les commentaires que vous pouvez avoir sont les bienvenus !
Si vous avez des questions, demandes, commentaires ou retours à partager avec nous, n'hésitez pas à nous rejoindre sur Slack !
Lire la suite
Explorez des sujets et analyses associés
Votre SOC n'a pas de problème de données. Il a un problème de coordination.

Workflows d'approbation de l'intelligence : garantir la qualité des données et rationaliser les processus
