Avez-vous déjà transformé votre SOC ?

L'une des façons dont nous travaillons avec notre communauté de partenaires est de fournir des services gérés aux utilisateurs finaux. Et comme c'est le cas dans presque tous les scénarios de déploiement, chaque environnement a son propre ensemble de configurations, d'exigences et parfois même de défis. C'est pourquoi nous avons décidé de vous présenter quelques-uns des défis les plus courants que nous avons rencontrés, afin de vous aider dans votre démarche.

Mais tout d'abord, jetons un coup d'œil à la liste des défis ci-dessous. L'un ou l'autre de ces problèmes se retrouve-t-il aujourd'hui dans votre centre d'opérations de sécurité (SOC) ?

• Coût élevé de la propriété: il s'agit du coût de la création et de la maintenance des cas d'utilisation de la gestion des informations et des événements de sécurité (SIEM), de l'attrition du personnel dans les rôles d'analyste de niveau 1 et de niveau 2, du recrutement et de la formation constants, ce qui entraîne une augmentation des coûts.
• Inefficacités en matière de sécurité: difficulté d'obtenir une couverture à 100 % des journaux et des cas d'utilisation en raison des coûts d'alimentation des journaux, des défis techniques et opérationnels ou d'une capacité limitée à effectuer une analyse médico-légale de l'évolution d'un incident.
• fatigue des alertes: les journaux ou les systèmes traditionnels basés sur les signatures génèrent trop d'alertes, trop de faux positifs ou les deux, et/ou difficulté à découvrir et à comprendre le contexte des alertes.

Si vous avez répondu par l'affirmative à l'un de ces défis, vous êtes au bon endroit.

Le SOC 1.0

Le SOC 1.0, ou SIEM SOC, a été la première évolution dans la mise en place d'une capacité de surveillance de la sécurité au sein d'une organisation. L'idée du SOC 1.0 est simplement de collecter tous les journaux provenant des pare-feu, des proxies, des serveurs d'authentification, des applications et des postes de travail, c'est-à-dire de tout ce qui le permet. Une fois cela fait, vous les regroupez dans une plateforme SIEM, où les données peuvent être facilement interrogées et corrélées, et où vous pouvez ingérer des indicateurs de compromission (IoC) ou des renseignements sur les menaces qui peuvent être comparés aux données des journaux.

C'est à ce moment-là que les choses sérieuses commencent et que l'on s'embarque dans l'élaboration de requêtes ou de cas d'utilisation pour trouver des actions malveillantes ou risquées dans toutes les données. En règle générale, vous commencez à réfléchir à la manière de créer des alertes lorsque certains événements, combinaisons d'événements ou seuils sont dépassés, afin que les analystes puissent répondre aux alertes et utiliser le SIEM avec d'autres outils et ressources pour enquêter sur les événements. Dans l'idéal, ce système serait mis en place de manière cloisonnée, ce qui signifie que les analystes doivent aller de console en console, d'outil en outil pour essayer de trianguler manuellement les alertes afin de comprendre ce qui se passe. En général, cette approche présente de nombreux avantages et est considérée aujourd'hui comme la norme de facto et la capacité fondamentale dans de nombreux SOC - pour les grandes et les petites organisations - mais il existe des problèmes fondamentaux.

Le scénario courant dans de nombreux environnements SOC 1.0 est le suivant :

• Il n'y a pas de registres adéquats
• Les journaux ne contiennent pas suffisamment de données pour permettre une détection adéquate des menaces.
• Il est coûteux d'élaborer et de maintenir les cas d'utilisation ou les règles de détection.
• Le coût du stockage des logs dans un SIEM devient un problème majeur pour les clients.
• L'approche basée sur les règles d'interrogation et l'analyse statistique n'est pas assez puissante pour détecter les attaquants furtifs.
• Le SOC est surchargé d'alertes, la plupart d'entre elles étant des détections faussement positives.
• Les analystes du SOC ont du mal à obtenir suffisamment d'informations sur le contexte de l'alerte, et le triage des alertes nécessite un travail manuel important.

Par conséquent, il existe un grand nombre d'offres d'emploi pour les cyber-analystes, les développeurs et les intervenants en cas d'incident, en raison du volume élevé de travail dans les SOC et du fait que le travail lui-même dans le SOC 1.0 est parfois banal et peu gratifiant, ce qui entraîne une forte rotation des ressources. Les coûts de fonctionnement d'un SOC 1.0 augmentent progressivement, tandis que la surface d'attaque contre laquelle il faut se protéger ne cesse de croître dans la réalité de l'après COVID-19. Dans le même temps, la cybercriminalité augmente, les attaquants deviennent plus sophistiqués, les attaques sont très spécifiques, furtives et adaptées à l'organisation cible.

Présentation de SOC 2.0

En raison des défis posés par l'approche SOC 1.0, de nombreuses organisations transforment leurs opérations SOC en SOC 2.0. L'approche SOC 2.0 est plus abordable, moins dépendante d'un grand nombre de personnes, détecte les attaques plus rapidement, introduit l'automatisation ainsi que de nouvelles techniques analytiques, et est prête à lutter contre des attaques inédites.

Les changements clés dans la transformation des opérations du SOC sont mis en évidence ici :

Cela signifie-t-il que le SIEM devient obsolète ? Non, le SIEM et les analyses basées sur les journaux restent des éléments clés. Le passage à SOC 2.0 utilise le SIEM pour ce pour quoi il est le mieux adapté, à savoir la détection des risques connus qui peuvent facilement être articulés dans des règles de requête. Un exemple de ceci pourrait être le voyage impossible, où nous faisons correspondre la distance géographique entre les lieux de connexion dans un laps de temps donné. Il s'agit d'un scénario pour lequel un cas d'utilisation peut facilement être créé et les journaux du serveur d'authentification sont facilement disponibles. Dans le SOC 2.0, le SIEM joue le rôle d'un seul point de vue alimenté par des détections de scores pré-analysés provenant de endpoint detection and response (EDR), détection et réponse aux incidents (NDR) et de sources d'analyse du comportement des utilisateurs et des entités (UEBA).

Pour les objectifs de détection, où la couverture des journaux n'est manifestement pas en place et où il s'agit davantage de reconnaître les modèles nuancés dans le comportement des utilisateurs et des applications, SOC 2.0 exploite l'apprentissage automatique avec les données du réseau et des points finaux. Imaginez que vous essayiez de créer un logiciel ou une règle traditionnelle pour distinguer et trier des images. Ce n'est pas vraiment faisable, mais avec un modèle d'apprentissage automatique de base, la reconnaissance des formes devient une activité triviale. Il en va de même pour l'analyse des schémas des attaquants dans le réseau, cloud, SaaS ou pour les applications. Machine Learning modèles peuvent être formés pour distinguer les schémas malveillants de l'application bénigne et du trafic réseau. L'intérêt de l'apprentissage automatique est qu'une fois le modèle créé, l'algorithme s'entraîne tout seul pour commencer à effectuer le travail de détection - ce qui signifie que les solutions d'apprentissage automatique ne nécessitent que peu ou pas de réglage et de personnalisation pour commencer à exécuter les tâches.

Avec SOC 2.0, les algorithmes d'IA enrichissent le contexte des détections, tout en corrélant et en notant les détections. Le rôle de l'analyste SOC est accru pour travailler sur les incidents prioritaires, où il peut rapidement appliquer ses connaissances et son expérience, ainsi que ses compétences médico-légales pour établir une chronologie et un dossier pour trier les comportements spécifiques remarqués tout en fournissant des conseils à l'équipe d'intervention pour qu'elle prenne des mesures. Tout cela permet à l'organisation de repenser ce qu'elle doit ingérer puisque toutes les détections ne sont pas basées sur des journaux. En outre, les solutions EDR et NDR fourniront au SIEM des alertes de détection classées par ordre de priorité plutôt que de simples données brutes.

Le SOC 2.0 ne s'appuie plus sur les systèmes IDS - les données sur les menaces (IP, domaines) sont analysées dans la solution NDR. Les pare-feu appliquent des règles en vol. Les antivirus et la protection du courrier électronique se chargent d'appliquer des signatures aux fichiers et aux charges utiles. Les attaquants ont tendance à crypter leurs données en transit, de sorte que l'application de signatures au trafic réseau a de moins en moins de sens. Enfin, lorsque l'automatisation est appliquée à la réponse aux incidents et qu'une détection de menace est automatiquement ou manuellement considérée comme vraie et sérieuse, les plateformes d'orchestration, d'automatisation et de réponse en matière de sécurité (SOAR) peuvent prendre le relais pour exécuter les actions nécessaires afin d'arrêter la progression des attaques conformément aux règles établies.

Perspectives d'avenir

Alors que SOC 1.0 est encore la norme dans de nombreuses organisations, de plus en plus d'entre elles adoptent l'approche SOC 2.0. Vectra joue un rôle clé dans la triade de visibilité SOC, car les données du nouveau réseau composé de services IaaS, SaaS et on-prem ne mentent pas. L'apprentissage automatique et l'IA améliorent considérablement le niveau d'automatisation et accélèrent la capacité de l'organisation à stopper les attaques avant qu'elles ne se transforment en brèches.

Découvrez comment Vectra peut vous aider à améliorer la visibilité de votre SOC ou commencez par planifier une démonstration.