Le sujet de l'intelligence artificielle, né dans les années 60, connaît actuellement un boom fou. Les ordinateurs battent les joueurs d'échecs et les fans de Go, parfois ils sont plus susceptibles d'être diagnostiqués avec un médecin, les réseaux de neurones (cette fois sans rapport avec l'esprit de trois ingénieurs du support technique) essaient sérieusement de résoudre des problèmes appliqués complexes, et quelque part à l'horizon se profile l'intelligence artificielle universelle, qui quand - Quelque chose remplacera son parent appliqué.
La sécurité de l'information ne reste pas non plus en dehors des frontières du battage médiatique autour de l'IA (ou de son évolution - ici, chacun décide pour lui-même). De plus en plus, nous entendons parler des approches nécessaires, des solutions en cours d'élaboration, et même (parfois timidement et incertain, et parfois fort et, malheureusement, peu crédible) des premiers succès pratiques dans ce domaine. Bien sûr, nous ne nous engagerons pas à parler pour la sécurité de toutes les informations, mais nous essaierons de déterminer quelles sont les réelles possibilités d'utilisation de l'IA dans le domaine SOC (Security Operations Center) qui nous concerne. Qui s'intéresse au sujet ou veut simplement se faufiler dans les commentaires - bienvenue au chat.
Taper l'IA pour les tâches SI, ou toutes les IA ne sont pas également utiles
Il existe de nombreuses approches de la classification de l'intelligence artificielle - en termes de types de systèmes, d'ondes évolutives du développement d'une direction, de types de formation, etc. Dans cet article, nous examinerons la classification des types d'IA du point de vue de l'approche d'ingénierie. Dans cette classification, l'IA est divisée en 4 types.
1. Approche logique (système expert en informatique) - L'IA est principalement conçue comme un système de preuve de faits complexes. Le système interprète tout objectif émergent comme une tâche qui doit être résolue par des méthodes logiques. Selon des sources, le système IBM Watson, tristement célèbre pour tous les fans d'échecs russes, utilise des approches similaires dans son travail.
L'essence de cette approche est que le système a pour la plupart deux interfaces principales: pour acquérir des informations (où la formation est effectuée par un expert dans le domaine) et pour résoudre un problème (où les connaissances et les techniques obtenues sont utilisées pour résoudre des problèmes logiques et pratiques).
Cette approche est le plus souvent prise en compte lorsque l'on parle des perspectives d'utilisation de l'IA dans la sécurité de l'information, nous allons donc la vérifier pour un examen plus détaillé à l'avenir.
2. Approche structurelle - lorsque l'une des principales tâches d'ingénierie de l'IA est l'émulation du cerveau humain avec sa capacité à structurer et analyser les informations. En fait, les flux de données fournis au système et les commentaires qui lui sont fournis (ce qui aide beaucoup de gens ordinaires, y compris les analystes SOC), elle apprend et améliore les algorithmes de prise de décision internes.
En raison de la possibilité de rétroaction détaillée, ces approches sont souvent utilisées en relation avec des tableaux de données structurées de manière conditionnelle. Il s'agit du traitement d'image, de la personnalisation des données, du balisage du contenu audio / vidéo ou d'autres informations. Dans la plupart des implémentations bien connues, le système, bien qu'il ne soit pas purement expert et ne nécessite pas de mode d'acquisition de connaissances, nécessite néanmoins un travail d'opérateur important pour former un flux de rétroaction stable et significatif. Il y a une ressemblance avec le travail du cerveau humain: pour que l'IA «grandisse», il faut apprendre ce qui est bon et ce qui est mauvais, ce qui est chaud, ce qui est froid, où est maman et où est un étranger.
3. L'approche évolutive - la culture de l'IA dans le processus d'échange de connaissances entre des programmes plus simples et la formation d'une nouvelle structure de code plus complexe. La tâche de l'évolution est avant tout la création d'un «look parfait» et l'adaptation à un nouvel environnement agressif, la survie, afin d'éviter le triste sort des dinosaures.
À mon avis, les chances d'une telle approche nous conduisant à l'intelligence artificielle, capable de résoudre des problèmes de sécurité de l'information ou de participer aux activités du SOC, sont faibles. Notre cyber-environnement est certainement assez agressif, des attaques se produisent tous les jours et en grand nombre, mais l'option de créer les conditions pour que l'environnement SI soutienne et stimule l'approche évolutive semble peu probable. Les personnes ayant une opinion alternative sur la question sont les bienvenues à commenter.
4. Approche de simulation - la création d'un simulateur d'actions dans la zone d'étude grâce à des observations à long terme du sujet simulé. Pour simplifier, la tâche consiste à lire tous les paramètres d'entrée et les données de sortie (résultats d'analyse, actions, etc.) afin qu'après un certain temps la machine puisse produire exactement les mêmes résultats que l'objet à l'étude, et potentiellement diffuser les mêmes pensées si l'objet était une personne.
Malgré l'attrait d'attacher Big Brother à l'analyste SOC, l'approche du BI semble également être de peu d'utilité. Tout d'abord, en raison de la difficulté de collecter et de séparer les nouvelles connaissances dans le domaine de la sécurité de l'information de toutes les autres (une personne est faible et est heureuse d'être distraite par des contextes externes même dans le processus de travail), et en raison de l'imperfection des outils d'observation (les shunts pour lire les informations n'ont pas encore été spécialement développés à Dieu).
Si vous examinez intégralement toutes les approches décrites, en particulier dans le contexte de leur application pour les tâches d'analyse SOC, une caractéristique commune est perceptible: l'IA bébé pour un bon développement doit être nourrie - avec des méthodes, des réponses correctes et les données les plus structurées qui lui expliqueront comment à l'avenir il devrait Construisez et prenez vos propres décisions, ou apprenez-lui à utiliser des interfaces d'informations externes. De plus, dans notre cas, ces interfaces doivent également être structurées et automatisées: si l'analyste SOC peut recevoir des informations sur la menace ou l'actif par téléphone, alors ce numéro ne fonctionnera pas avec l'IA.
Dans le cas général, une partie des processus de sécurité de l'information (détection des fraudes, protection des applications web, analyse des droits et références des utilisateurs) supporte réellement le principe des grands nombres et une structure «logique». Dans le cas de la détection d'incident, tout est beaucoup plus amusant.
AIIs ceci, ou les capacités de l'intelligence artificielle dans le contexte des processus SOC
Essayons maintenant de «poser» les approches logiques et structurelles de l'intelligence artificielle sur les processus SOC clés. Étant donné que dans les deux cas, une imitation de la pensée logique humaine est impliquée, cela vaut la peine de commencer à poser une question: que ferais-je, en tant qu'analyste SOC, pour résoudre ce problème ou obtenir une réponse quelque part - automatisée? Passons en revue les processus clés du SOC:
1. Le processus d'inventaire ou de collecte d'informations sur les actifs. Une tâche suffisamment importante, y compris pour l'IA, qui devrait recevoir un contexte sur les objets d'observation et avec son aide à apprendre.
En théorie, c'est un domaine fertile pour l'IA. Lorsqu'un nouveau système apparaît, vous pouvez le «comparer» de manière fiable avec ses voisins (en analysant le trafic réseau, la structure logicielle et la communication avec d'autres adresses IP) et à partir de là faire une hypothèse sur son objectif, sa classe et les informations stockées clés. Et si vous y ajoutez le contexte de création («le système a été écrit par Vasya, et Vasya dans notre entreprise est un spécialiste de la gestion de documents informatiques, et les dix derniers systèmes qu'il a créés étaient de la gestion de documents» ou «en même temps, 4 autres systèmes ont été créés qui indiquent clairement le but» etc.), puis procéder à un inventaire et à la comptabilité des actifs semble faisable pour la tâche d'IA.
Nuances émergentes ou problèmes externesA. Dans la pratique, nous observons un niveau d'entropie considérable chez les clients, même dans le cadre d'un système commercial distinct. Ici et caractéristiques du travail d'un ingénieur particulier, et une configuration d'interaction légèrement modifiée pour ce système, et des logiciels supplémentaires. Et aussi pour les processus de surveillance et de gestion des incidents, il est important pour nous de comprendre si le système est productif ou de test, si les données de combat y sont téléchargées ou non, et une douzaine d'autres problèmes mineurs qui sont généralement faciles à résoudre par téléphone et assez difficiles à isoler des flux d'informations.
B. Pour aborder le problème, à un certain stade, il est nécessaire de créer un environnement stérile conditionnel dans lequel nous savons toujours qui est qui et quelles tâches sont résolues. Les processus de même la création de base d'un modèle d'actif pour la plupart des clients ... eh bien, en général, nous ne parlerons pas de choses tristes, vous savez tout vous-même.
Néanmoins, nous notons la promesse d'utiliser l'IA dans cette tâche comme «un jour» et allons de l'avant.
2. Le processus de gestion des vulnérabilités. Bien sûr, nous ne parlons pas de l'analyse instrumentale de base et de l'identification des vulnérabilités et des défauts de configuration (ici même le ML en Python n'est pas nécessaire, pas comme l'IA sur Powerpoint - tout fonctionne sur des algorithmes de base). La tâche consiste à mettre les vulnérabilités identifiées sur la carte des actifs réels, à les hiérarchiser en fonction de la criticité et de la valeur des actifs menacés, à former un plan ... Et voici l'arrêt. Savoir vraiment quels actifs valent est une tâche que même un gardien de sécurité en direct ne peut souvent pas comprendre. Le processus d'analyse des risques et d'évaluation des actifs se termine généralement au stade de l'évaluation de la valeur des informations ou de l'alignement de cette évaluation sur l'entreprise. En Russie, pas plus d'une douzaine d'entreprises ont emprunté cette voie.
Mais, peut-être, dans le mode facilité (lorsque le coût d'une ressource ou sa criticité est estimé par une échelle relative de 10 ou 100 points), le problème peut certainement être résolu. De plus, les problèmes d'automatisation nous ramènent d'abord à l'article précédent - l'inventaire. Après cela, le problème est résolu par une analyse statistique classique, sans astuces d'IA complexes.
3. Analyse des menaces. Lorsque nous avons enfin inventorié tous les actifs, compris toutes les erreurs de configuration et les vulnérabilités possibles, il serait bien de mettre les vecteurs d'attaque et les techniques d'attaquant bien connus sur cette image. Cela nous permettra d'évaluer la probabilité que l'attaquant soit en mesure d'atteindre l'objectif. Il est idéal d'ajouter des statistiques sur les tests des employés pour déterminer la capacité de phishing et les capacités du service IS ou SOC à détecter les incidents (le volume de la partie contrôlée de l'infrastructure, le nombre et les types de scénarios de cyberattaque surveillés, etc.).
La tâche semble-t-elle résoluble? À condition que nous ayons réussi au cours des deux étapes précédentes, il y a deux nuances clés.
1. Les techniques et méthodes d'attaque d'un attaquant nécessitent également une interprétation de la machine d'entrée. Et il ne s'agit pas des IoC qui sont facilement décomposables et applicables, mais, tout d'abord, des attaquants TTP (Tactics, Techniques and Procedures), qui impliquent une chaîne de conditions beaucoup plus complexe («sous quel type d'entrée je suis vulnérable?»). Même une analyse de base des techniques bien connues de la matrice Mitre confirme que l'arbre des événements sera très ramifié, et pour une décision correcte sur la pertinence de la menace, chaque fork nécessite une algorithmisation.
2. Dans ce cas, le cerveau neuronal artificiel est complètement opposé au naturel - l'attaquant. Et la probabilité que des actions non standard, non décrites ou ne tombent pas directement dans des actions TTP, est extrêmement élevée.
4. Détection / détection de nouvelles menaces / anomalies, etc. Lorsque les gens parlent d'utiliser l'IA dans les SOC, ils désignent généralement ces processus. En effet, la puissance de calcul illimitée, le manque de focalisation de l'attention, Data Lake - sur quoi ne repose pas l'IA pour détecter de nouvelles anomalies et menaces, n'ont-ils pas été corrigés auparavant?
Le problème clé est que pour cela, vous devez au moins regrouper les activités par structures fonctionnelles / commerciales et actifs d'information (retour au point 1), sinon l'ensemble du flux de données énorme dans notre Data Lake n'aura pas le contexte requis pour détecter les anomalies. L'utilisation de l'IA dans ce domaine est limitée à une gamme clairement définie de tâches appliquées; dans le cas général, elle produira trop de faux positifs.
5. L'analyse des incidents est la «licorne» de tous les amateurs d'automatisation sur les problèmes SOC: toutes les données sont automatiquement collectées, les fausses alarmes sont filtrées, des décisions éclairées sont prises
et la porte de Narnia se cache dans chaque garde-robe .
Malheureusement, cette approche est incompatible avec le niveau de désordre d'entropie que nous voyons dans les flux d'informations des organisations. La quantité d'anomalies détectées peut changer quotidiennement - non pas en raison du volume croissant de cyberattaques, mais en raison de la mise à jour et de la modification des principes des logiciels d'application, de la modification des fonctionnalités utilisateur, de l'humeur du directeur informatique, de la phase de lune, etc. Afin de travailler au moins d'une manière ou d'une autre avec les incidents reçus de Data Lake (ainsi que de UBA, NTA, etc.), l'analyste SOC devrait non seulement continuer pendant longtemps et rechercher constamment les causes probables d'un comportement aussi étrange du système, mais aussi avoir une vue complète des systèmes d'information: pour voir chaque processus en cours et mise à jour, chaque ajustement du registre ou des indicateurs de flux réseau, pour comprendre toutes les actions effectuées dans le système. Même si vous oubliez le flux énorme d'événements que cela provoquera et le nombre d'ordres de grandeur que le coût d'une licence pour tout produit utilisé dans le travail du SOC augmentera, il y a toujours d'énormes coûts d'exploitation pour l'entretien d'une telle infrastructure. Dans l'une des sociétés russes que nous connaissions, nous avons réussi à «combiner» tous les flux réseau, à activer la sécurité des ports, à configurer NAC - en un mot, à tout faire en Feng Shui. Cela a permis une analyse et une enquête de très haute qualité de toutes les attaques réseau, mais en même temps, le nombre d'administrateurs réseau prenant en charge cet état a augmenté d'environ 60%. Si une solution IB élégante vaut de tels coûts supplémentaires - chaque entreprise décide et évalue par elle-même.
Par conséquent, le récepteur téléphonique, la communication avec les administrateurs et les utilisateurs, les hypothèses qui nécessitent une vérification sur les stands, etc., restent le lien nécessaire dans l'analyse des incidents. Et ces fonctions d'IA sont mal déléguées.
En général, jusqu'à présent, nous disons l'utilisation stricte de l'IA dans l'analyse des incidents, "je ne le crois pas", mais nous espérons vraiment que dans un proche avenir, nous serons en mesure de donner à l'IA au moins un inventaire des actifs et de la gestion de la vulnérabilité.
6. Réponse et réponse aux incidents. Curieusement, dans cette partie, l'utilisation de l'IA semble être un modèle assez viable. En effet, après une analyse qualitative, une classification et un filtrage des faux positifs, en règle générale, il est déjà clair que faire. Oui, et dans le travail de nombreux SOC, les manuels de base pour répondre et bloquer peuvent être exécutés même par les IB, mais par des informaticiens. C'est un bon domaine pour le développement possible de l'IA ou des approches plus simples de l'automatisation.
Mais, comme toujours, il y a des nuances ...
A. Encore une fois, je souligne que pour le succès du travail de l'IA à ce stade, il est nécessaire que la personne précédente soit un analyste, et cela doit être fait de manière aussi complète et qualitative que possible. Ce n'est pas toujours une tâche facile.
De la part de l'informatique et des affaires, vous rencontrerez un rejet brutal de l'automatisation des playbooks, même de base, pour répondre (bloquer les adresses IP et les comptes, isoler un poste de travail), car tout cela est lourd de temps d'arrêt et de perturbation des processus métier. Et, bien que ce paradigme n'ait pas été testé avec succès par la pratique et le temps - au moins en mode semi-manuel sur le feu vert de l'analyste, il est probablement prématuré de parler de transfert de fonctions vers une machine.
Voyons maintenant la situation dans son ensemble. Certains processus ne sont pas encore aliénés en faveur de l'IA, d'autres nécessitent l'élaboration et la maintenance du contexte d'infrastructure complet. Il semble que le moment de l'adoption généralisée de ces technologies ne soit pas encore venu - la seule exception est la tâche d'améliorer la qualité de la détection des incidents en identifiant les anomalies. Cependant, il y a des raisons de croire que les tâches SOC énumérées sont, en principe, susceptibles d'automatisation, ce qui signifie qu'à long terme, l'IA peut tout à fait y trouver sa place.
Skynet n'est pas prêt à gagner
En finale, je voudrais souligner quelques moments très importants, à notre avis, qui nous permettent de répondre à une question commune: «Une IA peut-elle me remplacer par la première ligne / commande de Threatunting / SOC?
Premièrement, même dans les très grandes industries rationalisées et automatisées, où la plupart des fonctionnalités sont données aux machines, l'opérateur est toujours présent. Cela peut être observé dans tous les secteurs de notre économie. Les tâches de l'opérateur en ce sens sont d'une simplicité déterministe - par leur facteur humain, éliminer le «facteur machine» et stabiliser la situation de leurs propres mains en cas de défaillance / accident / violation de l'exactitude du processus. Si nous automatisons ou cybernétisons les tâches SOC, il est alors automatiquement nécessaire d'attirer un spécialiste spécialisé solide, capable d'évaluer rapidement l'impact des erreurs machine et l'efficacité des actions entreprises. Par conséquent, l'automatisation et le développement de l'IA, même à l'avenir, ne mèneront probablement pas au rejet d'un quart de travail 24h / 24.
Deuxièmement, comme nous l'avons vu, toute intelligence artificielle d'une manière ou d'une autre nécessite un renouvellement des connaissances et des commentaires. De plus, dans le cas du SOC, il ne s'agit pas seulement de changer les vecteurs d'attaque ou le contexte d'information externe (qui peut en théorie faire partie des packages de formation / expert, etc.), mais, tout d'abord, le contexte d'information de vos incidents, votre organisation et vos processus métier. Ainsi, l'IA ne pourra pas non plus remplacer les analystes experts à plein temps de l'IA. Au moins dans un avenir proche.
Ainsi, à notre avis, toute approche de l'intégration de l'IA dans SOC au stade actuel ne peut être considérée que comme des éléments d'automatisation du travail avec le contexte et la solution de certaines sous-tâches analytiques. Un processus aussi complexe que celui d'assurer la sécurité des informations n'est pas encore prêt pour le transfert complet aux robots.