Aujourd'hui, nous allons parler du Security Operations Center (SOC) de la part des personnes qui ne le créent pas et ne le configurent pas, mais vérifions comment les autres l'ont fait. L'efficacité du SOC construit pour votre entreprise indépendamment ou par quelqu'un de l'extérieur est vérifiée. Le contrôle répond à la question «Le SOC remplit-il les tâches qui lui sont assignées ou non, et quelle est son efficacité?». Après tout, la présence de SOC ne signifie pas qu'il fonctionne comme il se doit et vous êtes au courant de tout incident possible et d'autres problèmes de sécurité. Nous raconterons notre expérience en vérification SOC dans différentes entreprises au sein de nos projets.



Pour ceux qui savent déjà ce qu'est le SOC et avec quoi il se boit, nous vous suggérons de passer immédiatement à la deuxième partie de l' article. Les autres sont invités à lire l'article complet.

Partie 1. Un peu de SOC pour les débutants

La protection des systèmes d'information passe avant tout dans presque tous les secteurs. Tout accès non autorisé à l'information peut entraîner de graves problèmes pour l'entreprise.

Le système d'information de toute entreprise, même la plus petite, est complexe, et toutes ses parties doivent être protégées selon le même principe - d'abord organisationnel, puis mesures préventives, puis outils de surveillance qui détectent les anomalies, et outils de réponse. Les gens sont à la dernière étape, mais non des moindres, de la lutte contre les menaces, bien qu'il arrive qu'un problème de sécurité puisse être résolu sans impliquer des personnes, par exemple en bloquant automatiquement les ports ou en déconnectant une machine d'un réseau partagé. Les outils utilisés pour protéger chacun des composants du système peuvent varier d'une entreprise à l'autre, mais il existe une tendance générale - progressivement, les entreprises, quelle que soit leur taille, viennent à l'idée d'introduire SOC - Security Operation Center.

Il y a plusieurs raisons à cela:

• L'utilisation du SOC réduit le coût du suivi manuel des incidents de sécurité
• les événements du système se rassemblent en un seul endroit, moins susceptibles d’être perdus;
• SOC vous permet de configurer des règles pour classer les événements comme des incidents de sécurité en fonction des besoins et des caractéristiques d'une entreprise particulière;
• SOC vous permet de minimiser le temps de détection et de réponse aux incidents de sécurité, réduisant ainsi les dommages potentiels pour l'entreprise;
• les journaux qui tombent dans le SOC sont mis en un seul regard, ce qui vous permet d'enquêter efficacement sur les incidents de sécurité, même si un attaquant tente de remarquer des traces de sa présence dans le système.

SOC est une infrastructure avec de nombreux composants interconnectés, sa base est le SIEM (Security information and event management). SIEM est un système de collecte, de normalisation et de corrélation de données qui collecte les journaux des serveurs Web, des machines hôtes et d'autres composants d'infrastructure, ainsi que des outils de sécurité des informations installés sur les appareils du réseau de l'organisation, les corrèle et les traite pour les ramener à la normale. C'est la tâche principale de SIEM - d'amener un grand nombre de journaux de différentes sources dans un seul format pour la commodité de détecter les relations entre eux. Cela est nécessaire pour une autre composante des analystes SOC - SOC qui, en regardant les énormes listes de journaux de SIEM, doivent réagir seuls à certains événements ou les transférer au travail de spécialistes de la sécurité.

Il n'y a pas deux SOC identiques car sa configuration est individuelle pour chaque organisation. Les principales étapes de la création d'un SOC sont les suivantes:

• définir une infrastructure protégée, tant sur le plan organisationnel que technique;
• l'installation de tous les moyens de protection et de surveillance possibles / nécessaires, ainsi que leur configuration;
• sélection d'un SIEM adapté et son ajustement en fonction des caractéristiques de l'entreprise;
• créer des règles de corrélation d'événements;
• sélection de l'équipe SOC - personnes dont le travail consistera à surveiller les événements et à apporter des corrections aux règles de corrélation, ainsi qu'à répondre aux événements de sécurité.

Même une fois que tout est défini, installé et configuré, personne ne peut garantir que SOC fonctionne maintenant comme vous le souhaitez ou comme le montrent les belles présentations des développeurs SIEM. Le problème fondamental de l'utilisation de tout moyen de protection est que pratiquement personne ne sait avec quelle efficacité ils fonctionnent. Il est important non seulement de les installer et de les exécuter, mais également de s'assurer que les mesures prises sont efficaces. Le niveau de maturité de l'entreprise en matière de sécurité est également extrêmement important.

Étant donné que le SOC est une structure complexe et multi-composants, il est important de comprendre qu'à chacune des étapes répertoriées de sa création, quelque chose peut mal tourner. Et cela est susceptible d'affecter la sécurité globale du système et l'efficacité du SOC lui-même.

Partie 2. Que se passe-t-il si vous ne vérifiez pas l'efficacité du SOC, mais laissez tout tel quel?

Pour commencer, quelque chose peut mal tourner, même avec le moindre changement dans l'infrastructure de l' organisation. Et ils se produisent assez souvent - quelqu'un part, de nouvelles personnes arrivent, quelque chose se casse, le matériel et les logiciels sont mis à jour, et bien plus encore. Dans ce cas, les paramètres du SPI et les règles de corrélation doivent être rapidement modifiés, mais ils l'oublient souvent et lorsqu'ils se souviennent, il est trop tard.



La partie suivante du SOC où des erreurs peuvent se produire est le moyen de protection à partir duquel les informations pénètrent dans SIEM, peuvent être configurées de manière incorrecte et ignorer les actions visant le système de l'extérieur. Et si l'action de l'attaquant n'est détectée par aucun des SZI existants, il n'entrera pas dans les journaux et ne sera pas dans SIEM, et le service de sécurité ne le saura probablement pas bientôt.



Le problème peut être dans SIEM . Cela peut ne pas fonctionner comme vous le souhaitez. Les événements qui y tombent peuvent être corrélés de manière incorrecte en raison d'erreurs dans les règles de corrélation, ce qui entraînera le saut des actions de l'attaquant. Il convient de préciser ici qu'il n'y a pas toujours suffisamment de données provenant d'une seule source. Il existe des cas où, pour déterminer les incidents de sécurité, il est nécessaire de combiner les données de plusieurs sources à la fois afin d'avoir une image complète de ce qui se passe dans le système. Mais il peut s'avérer que la règle est configurée de telle sorte que pour déterminer ce qui s'est produit, l'incident peut ne pas contenir suffisamment de données provenant d'une seule source, ce qui indique le fait de son achèvement. C'est-à-dire un puzzle composé de données provenant de plusieurs sources ne fonctionnera pas. En outre, les règles de certains événements de sécurité peuvent ne pas exister du tout.

Au stade de la corrélation d'événements dans SIEM, plusieurs problèmes peuvent survenir à la fois. L'un d'eux peut être un retard dans la transmission des événements à partir de certaines sources, ce qui peut interférer avec une corrélation réussie.

Les règles de classification des événements en tant qu'incidents dans SIEM peuvent ne pas être correctement configurées seules ou peuvent ne pas être disponibles pour aucun événement. De plus, les incidents ont généralement un niveau de gravité qui, s'il n'est pas correctement identifié, peut entraîner de gros problèmes.



Les personnes travaillant avec SIEM, dont le travail consiste à répondre aux incidents de sécurité, peuvent également provoquer des attaques manquées et des problèmes de sécurité des informations ultérieurs. Ils peuvent manquer certains signaux de SIEM ou réagir incorrectement aux actions de l'attaquant pour diverses raisons. Il y a aussi le problème que les gens abandonnent tôt ou tard et que les nouveaux employés ont besoin de temps pour se former.

Compte tenu de ce qui précède, les tests SOC pour vérifier les performances sont extrêmement importants à la fois au stade de la mise en œuvre SOC et au fil du temps. Les spécialistes de notre entreprise ayant déjà une expérience en la matière, nous avons décidé de décrire les principaux points et nuances.

Partie 3. Vérification de l'efficacité du SOC

Les tests SOC dans une entreprise peuvent être effectués selon plusieurs scénarios. Parlons de ceux qui nous semblent les plus efficaces.

Les tâches de test SOC incluent des tests de sécurité en reproduisant des scénarios de comportement typiques inhérents aux cybercriminels. Cela comprend:

• itérer à travers les comptes d'autres utilisateurs en utilisant la force brute, ainsi qu'en utilisant la technique de pulvérisation de mot de passe. Cette technique est possible si vous avez accès à la liste des comptes existants dans le système, par exemple via le carnet d'adresses du client de messagerie. D'après notre expérience, les techniques de pulvérisation de mots de passe sont souvent oubliées et, par conséquent, les règles SOC peuvent difficilement détecter une telle attaque;
• pomper des données à partir d'une ressource Web, que ce soit un wiki d'entreprise ou un gestionnaire de tâches. Une telle attaque peut être effectuée, notamment en utilisant divers mécanismes d'exploration de sites Web et de répertoires bruts. Séparément, les auditeurs prêtent attention aux services API et à leurs capacités;
• tentatives répétées d'accéder à des ressources ou à des projets qui ne relèvent pas de la compétence du rôle pour le compte duquel l'attaquant travaille. Un exemple simple est la tentative d'autoriser un utilisateur d'un groupe de développeurs sur les ressources des administrateurs réseau et des services de sécurité;
• Tente de télécharger une grande quantité d'informations à partir du réseau d'entreprise à l'aide de techniques de filtrage de contournement. Il s'agit principalement de tunnels DNS et icmp, mais il est parfois judicieux de commencer par des vérifications plus simples, par exemple, essayez de rechercher un port tcp ou udp ouvert à l'extérieur, ainsi qu'une passerelle supplémentaire. Soit dit en passant, pour rechercher des passerelles, il y a une implémentation révisée d'un outil populaire de l'un des employés.

Une liste similaire de contrôles peut être prolongée pendant longtemps. Il est primordial de se laisser guider par les besoins réels du client et les contrôles mis en œuvre par lui.

Les tests SOC peuvent être effectués de deux manières:

• aveuglément - boîte noire;
• avec des connaissances en infrastructure - whitebox.

Plus de détails sur chacun d'eux.

Tout d'abord, vous devez vérifier le fonctionnement de SOC en mode de test de boîte noire. Son essence est que les employés du département SOC ne sont pas au courant du travail en cours et répondent à tous les événements en mode combat. Les auditeurs / pentesters ont accès au réseau de l'entreprise, et les comptes peuvent également être fournis à partir des services les plus utilisés dans l'entreprise.

Un tel modèle suppose qu'un attaquant qui ne dispose d'aucune information supplémentaire a accédé au réseau de l'entreprise et à l'un des comptes existants de manière inconnue. Les actions d'un tel attaquant se caractérisent par un degré élevé de caractère aléatoire et de «bruit». Il scanne activement le réseau, parcourt les répertoires, les comptes, envoie tous les exploits connus de lui à tous les ports, lance des applications Web XSS, SQLi, RCE, SSTI, NoSQLi, etc. avec des vecteurs. En général, il se comporte de manière extrêmement agressive dans l'espoir de pirater au moins quelque chose. Lors de l'audit, les auditeurs imitent les actions d'un tel attaquant, en conservant un degré d'aliénation mentale donné, mais sont prêts à s'arrêter à tout moment à la demande du service SOC ou en cas de problème technique. Soit dit en passant, un résultat inattendu et agréable peut être la découverte de services et d'applications vulnérables dans l'infrastructure de l'entreprise.

Un autre modèle de test est la boîte blanche. Dans ce cas, le scénario d'un employé sans scrupules est élaboré. Habituellement, à ce stade, les auditeurs connaissent bien le réseau du client et peuvent jouer un tel rôle. Le comportement d'un attaquant potentiel dans ce cas peut être caractérisé par la grande sélectivité à la fois des moyens et des cibles de l'attaque. Ici, il est déjà possible de faire des parallèles avec les attaques APT . Les auditeurs n'attaquent que les endroits les plus faibles à leur avis et utilisent des vecteurs d'attaque bien pensés et étroitement ciblés, et tentent également d'accéder à des informations sensibles en dehors de la compétence de leur rôle de compte avec la tentative ultérieure de les pomper hors du périmètre sécurisé. Ils essaient d'effectuer toutes les actions de manière à passer inaperçus auprès des services de sécurité de l'entreprise.

Après les tests, l'analyse et la comparaison des résultats obtenus par les auditeurs et des incidents détectés par les employés de SOC commencent généralement. Cette étape fournira une image générale de l'efficacité des travaux actuels du SOC et pourra servir de point de départ à tous les plans futurs visant à étendre les contrôles et approches existants.

Enfin, lorsqu'une idée de la sécurité de l'infrastructure testée est compilée, les auditeurs peuvent utiliser le test de la boîte blanche pour analyser l'ensemble de règles existant, ainsi que les événements sur la base desquels ces règles sont formées. Cette interaction entre les auditeurs et les analystes SOC peut être très productive, et pendant la consultation aidera à identifier les erreurs logiques et les omissions dans la configuration des composants SOC. Leur racine est généralement le manque de compréhension par les analystes SOC de la façon dont un véritable attaquant peut agir et des astuces qu'il peut effectuer sur les systèmes.

Conclusion

Les services les plus critiques qui méritent une attention particulière sont testés séparément à l'aide de deux modèles d'intrus.

Un ensemble de mesures similaires vous permet de:

• accroître considérablement la sensibilisation des responsables de la sécurité à l'état de leur infrastructure;
• mener des exercices militaires pour le département SOC avec la possibilité d'obtenir des conseils d'experts dans le domaine de l'audit;
• détecter et corriger les erreurs existantes dans le travail de SOC, ainsi que généralement augmenter la sécurité de l'entreprise.

Pour l'aide à la rédaction de cet article, je remercie Denis _ttffdd_ Rybin et Ivan Chalykin .