Le V SOC Forum, le plus grand événement sur la pratique de détection et d'analyse des incidents en Russie, débutera demain. Je suis sûr que de nombreux lecteurs de ce hub seront là et entendront de nombreux reportages professionnels dans ce domaine de la sécurité de l'information. Mais en plus des termes, définitions et pratiques établies, qui sont traités au SOC Forum, dans la vie réelle, chacun de vous a probablement entendu beaucoup d'opinions différentes sur le fonctionnement du SOC, la protection contre les attaques APT, etc. Aujourd'hui, nous allons discuter de plusieurs mythes et légendes populaires.
Nous sommes intéressés par votre avis sur chacun d'eux, nous attendons donc vos commentaires. Bienvenue au chat.
Mythe 1 - SOC sur une chaîne, ou la magie de l'analyse du trafic réseau
Très souvent, lorsque nous discutons avec le client d'une protection complète contre les intrusions externes, nous entendons: «Et nous avons le matériel A, il est enrichi par l'expertise du fournisseur et les informations sur les nouvelles menaces, et il nous protège complètement contre les attaques externes.» Et bien, si après ces mots on nous montrait une solution multi-module Anti-APT - il y aurait des questions, mais il y en aurait beaucoup moins. Le plus souvent, derrière ce "périphérique universel" se trouve un IDS ordinaire, parfois doté de fonctionnalités de base pour analyser le trafic https. Nous ne remettons pas en cause l'expertise des vendeurs dans le domaine de la cybersécurité et leur connaissance des activités des hackers, ainsi que l'utilité d'enregistrer et d'analyser le trafic réseau (ce sujet sera certainement abordé à plusieurs reprises au Forum), mais nous souhaitons néanmoins nous concentrer sur les limites de l'approche, avec dont SOC se concentre uniquement sur les événements du réseau.
- Commençons par la base et certains déjà battus. Depuis 2013, nous observons des attaques de pirates informatiques menées sans l'utilisation de logiciels malveillants en tant que tels et, au moins, sans module d'interaction avec le serveur de gestion. Aux attaquants viennent les outils d'administration à distance légitimes, qui, avec le fichier de configuration correct, ne se distinguent pas des utilisateurs qui aiment travailler à domicile, ou du travail des administrateurs à distance dans les entreprises avec un faible niveau de maturité informatique. Au niveau des événements de réseau, il est tout simplement impossible de distinguer une session d'une autre, et pour une analyse complète de la méthode et des raisons de démarrer une session, les informations des systèmes d'extrémité sont nécessaires.
- Si l'idée de RAT est dégoûtante pour l'attaquant ou si elles ne sont pas applicables dans un cas d'attaque spécifique, le protocole https vient à la rescousse comme un moyen d'interaction. Sur une copie du trafic, le décryptage du protocole n'est pas possible, le capteur doit donc se contenter uniquement d'informations sur les en-têtes de paquets. Ceci n'est utile que lorsque le centre de contrôle se trouve dans une zone spécifique et peut être calculé par IP. Mais le plus souvent, nous parlons de grands services d'hébergement ou de services publics (nous avons écrit sur le piratage de pages Wordpress plus tôt ), ce qui ne nous permet pas d'identifier où se trouve la connexion légitime et où est compromise.
- Pour toute son utilité, les connexions réseau (et nous parlons généralement d'un morceau de fer dans la zone du périmètre) n'enregistrent que la relation entre le centre de contrôle et la chaîne supérieure de clients de robots. Souvent, les attaquants actuels utilisent une chaîne de serveurs C&C proxy (le premier niveau de capture d'infrastructure) pour communiquer avec les clients de robots internes. À ce stade, les restrictions sur l'emplacement de l'équipement ne détectent pas complètement l'attaque.
- Avec toute la variété des actions d'un attaquant, il n'a périodiquement plus besoin de provenir d'Internet. Il est possible de compromettre un compte d'accès à distance, puis de travailler sous les droits légitimes d'un administrateur ou d'un utilisateur. De plus en plus, les groupes utilisent la méthodologie de la chaîne d'approvisionnement, déclenchant une attaque en piratant un entrepreneur, qui a souvent un canal statique et mal contrôlé vers l'infrastructure et tous les mêmes comptes privilégiés. Il y a de plus en plus de vecteurs chaque année, et ils sont de plus en plus éloignés des remèdes classiques.
- En général, SOC ne consiste pas seulement à lutter contre les pirates. Les attaquants internes, la violation des politiques SI ou la fraude, le téléchargement ou la compromission de données client, et bien plus encore, font également partie d'une approche SOC globale. Et cela nécessite des techniques et des outils beaucoup plus complexes dans son travail.
Mythe 2 - SOC sans jambes ou travail sans première ligne
Une de nos légendes préférées. Blagues sur SOC, où 1 seule personne travaille, il est donc un petit 1er, un petit 2e et un petit 3e support, déjà inondé Internet. Mais beaucoup de clients, après avoir entendu beaucoup de rapports différents et avoir lu des articles, commencent à parler de la nécessité d'une pièce magique de fer / procédure / technologie (soulignée si nécessaire) qui automatisera et résoudra tous les problèmes de la première ligne. Et comme souvent dans la tête du client, la 1ère ligne équivaut au mode de fonctionnement 24 * 7 (tous les autres, en règle générale, fonctionnent selon le calendrier standard), cela crée automatiquement le sentiment d'une réduction significative des coûts de personnel et génère des conversations dans la clé «1ère ligne ne fait pas nécessaire, commençons à construire tout de suite avec le second. "
À notre avis, le problème clé de cette légende est la confusion terminologique. Souvent, lorsque le locuteur parle de la 1ère ligne, il est guidé par les pratiques ITIL, où les tâches atomiques tombent vraiment entre les mains des opérateurs:
- réception des tâches
- classification
- ajout de contexte (atout ou système d'information)
- priorisation ou priorisation
- Nomination au responsable du système / examen / file d'attente.
En ce qui concerne ce type de tâches, bien sûr, aucune première ligne dédiée n'est nécessaire: ces processus, bien que pas faciles, sont complètement automatisés. Ce que nous entendons par la première ligne, nous l'avons déjà écrit plusieurs fois - par exemple
ici ). Pourtant, la première ligne ne remplace pas l'automatisation, ni même une équipe travaillant exclusivement sur un playbook. Ces employés sont curieux et recherchent, même s'ils n'ont que des compétences de base pour analyser les événements et enquêter sur les incidents. En termes ITIL, une telle ligne serait appelée 2e, ce qui supprime immédiatement toutes les questions et les écarts.
Je ne voudrais pas ignorer les questions 24 * 7. À propos de l'organisation du quart de travail, de l'efficacité des opérateurs et des analystes la nuit, de la cécité psychologique lors de la visualisation des événements, trop de choses ont été dites. Les conclusions intégrales sont à peu près les mêmes: la première ligne SOC et un décalage 24h / 24 deviennent inefficaces et inutiles. Pour notre part, depuis de nombreuses années, nous avons également essayé différentes méthodes et pour le moment, le niveau fédéral de SOC nous permet de minimiser les risques de fatigue des spécialistes pendant le quart de nuit (un incident critique est simplement envoyé dans un fuseau horaire différent), néanmoins, je voudrais noter quelques points.
- Réduire les temps de travail pour l'opérateur est une très bonne idée. Travailler sur le principe du devoir informatique pendant un jour ou trois en sécurité de l'information est plutôt impossible. Cependant, il est très important de rester concentré sur les incidents ...
- MAIS ... l'opérateur de la 1ère ligne ne s'assoit pas, comme l'opérateur du film "The Matrix", regardant le flux d'événements bruts à la recherche d'anomalies. Au moins dans aucun SOC que nous connaissons, nous n'avons rencontré une telle approche. Son travail consiste à analyser des rapports et des chasses réguliers, ou à élaborer des scénarios pour identifier les incidents. Dans ce mode de changement d'attention et de types d'activité (avec le juste équilibre des nombres en jeu), les risques de cécité psychologique rapide nous semblent minimes.
Et en conclusion - peu importe le chemin parcouru par l'automatisation, il est habituel de laisser un spécialiste qui surveille la situation avec des machines et des robots sur n'importe quel site de production critique. Et si votre fourchette dans ce cas est «l'automatisation peut-elle m'aider à ne pas allouer 5-6 taux pour le quart de travail», alors notre réponse est sans équivoque: elle ne le peut pas.
Mythe 3 - SOC parfait sans interruption, ou nous travaillons sans faux positifs
Plus vous créez de SOC ou travaillez avec un fournisseur MSSP / MDR, plus vous voulez l'idéal. Maintenant, beaucoup de clients sont passés par les tuyaux d'incendie, d'eau et de cuivre des premières approches indépendantes du projectile ou des pilotes / contrats avec des fournisseurs externes et tout le monde essaie en quelque sorte de rechercher l'idéal. Et l'idéal aux yeux du chef / responsable du service extérieur s'exprime généralement par la phrase "chaque alerte est un incident confirmé" ou "nous ne surveillons pas les soupçons - nous enregistrons des attaques". Et en termes d'aspects clés de l'efficacité, il est difficile de contester cette affirmation. Mais, comme toujours, le diable est dans les détails.
La plupart des SOC visent une analyse efficace et approfondie de l'incident sur toutes les informations disponibles. Et ils approchent de plus en plus de la perfection, lorsqu'ils ont l'occasion de recevoir
des journaux de bord pour elle. Examinons un exemple d'incident sur les faits de fonctionnement des indicateurs de réseau du logiciel antivirus (l'adresse de communication avec le centre de contrôle) - pour les identifier, vous avez juste besoin de quelques informations sur les flux réseau vers Internet, par exemple, les journaux de pare-feu, mais ils donnent souvent un faux résultat. Il suffit à l'attaquant de cacher son serveur de gestion de malware sur l'hébergement, et nous rencontrerons automatiquement un grand nombre de faux positifs. Pour un filtrage et une analyse efficaces de l'incident, il est nécessaire de localiser l'activité sur l'hôte initiateur (processus déclenchés, sockets ouverts, etc.). Et cela nous amène à la nécessité de connecter les événements de tous les hôtes du réseau.
Total: pour que SOC se rapproche de la possibilité de détecter exclusivement des attaques, sans faux positifs, nous devons assurer une couverture de surveillance maximale de l'infrastructure - idéalement, collecter TOUS les journaux de TOUS les objets.
Cela nous amène à plusieurs problèmes à la fois.
- Opposition réelle des services informatiques à l'augmentation du niveau d'audit ou à l'installation de systèmes supplémentaires de collecte (afin d'éviter le mal, nous n'aborderons même pas le sujet de la connexion des segments ACS et des technologues). Les tests de compatibilité, une augmentation imprévisible de la charge sur les systèmes et d'autres facteurs qui peuvent affecter la disponibilité globale de l'infrastructure sont le déclencheur de la prochaine phase de la guerre entre l'informatique et la sécurité de l'information. Et le plus souvent, ils laissent simplement de gros points blancs sur la carte de surveillance des infrastructures du SOC.
- Maintien d'une couverture complète. Il n'est pas possible de collecter tous les journaux de tous les serveurs. Par exemple, dans les nouveaux systèmes, les journaux peuvent tout simplement ne pas être inclus. Souvent en cours de changement de serveurs, les paramètres d'audit sur les postes de travail et les restrictions d'accès sont partiellement ou complètement perdus. De plus, les paramètres doivent être mis à jour à mesure que de nouveaux vecteurs d'attaque apparaissent. Tout cela crée des coûts opérationnels pour fournir une couverture complète, nettement plus élevés que souvent les risques d'une revue incomplète par le suivi, et certainement plus élevés que les coûts d'une éventuelle fausse réponse positive.
- Le troisième problème nous amène à l'ancien jeu DOOM. Parce que, entre autres, une couverture complète vous oblige à saisir des codes.
a. IDKFA - munitions complètes sous forme de capacités de serveurs sans fin pour la collecte et le stockage d'événements et, ce qui est beaucoup plus triste d'un point de vue économique, - licences sans fin pour SIEM et d'autres outils SOC.
b. IDDQD est une équipe SOC énorme et immortelle qui, à chaque incident, sera en mesure d'analyser toutes ses caractéristiques évidentes et indirectes.
La coïncidence de tels facteurs, tâches et le montant des budgets pour la sécurité de l'information est considérée comme le cas d'une réunion de l'éléphant vert et n'est donc pas considérée comme une situation typique dans la vie du SOC. Ainsi, identifier uniquement les attaques confirmées (avec tout le désir d'analyser le plus profondément possible avec des outils automatiques) est un petit rêve fantastique des agents de sécurité modernes.
Au lieu d'une postface
Nous avons essayé de discuter uniquement des mythes les plus courants de l'industrie du bâtiment SOC. Par conséquent, dans les backwaters complexes du début des processus de surveillance et de réponse aux incidents, nous vous conseillons d'être aussi sceptiques sur les informations entrantes, de les vérifier dans différentes sources et de maximiser la peur de la
contrefaçon de jugements non confirmés.
Et que la Force soit avec vous;).