Vous en savez peut-être peu sur le SOC, mais il sera toujours intuitivement clair qu'il n'y a que deux choses qui comptent le plus dans son travail: identifier les incidents et y répondre. Dans le même temps, si vous ne prenez pas la situation où nous avons affaire à une fraude interne complexe ou à des signes d'activité d'un groupe professionnel, la réponse consiste généralement en un certain nombre de mesures techniques très simples (suppression du corps viral ou du logiciel, blocage d'accès ou de compte) et de mesures organisationnelles (clarification des informations des utilisateurs ou vérification et enrichissement des résultats de l'analyse dans des sources inaccessibles au suivi). Cependant, pour un certain nombre de raisons, le processus de réponse client a commencé à changer considérablement ces dernières années, ce qui a nécessité des changements de la part du SOC. De plus, puisque nous parlons d'une réponse, où «pas seulement tout» est important - et la précision,à la fois l'exhaustivité et la rapidité d'action - il est fort probable que si votre SOC interne ou externe ne prend pas en compte les nouvelles exigences de ce processus, vous ne pourrez pas gérer l'incident normalement.
Désormais, nombre de nos clients sont plus à l'aise pour recevoir une réponse en tant que service «cycle complet» - dans ce cas, nous bloquons l'attaque contre les défenses de l'entreprise et accompagnons le processus de réponse dans la zone de responsabilité du service informatique. Par exemple, nous aidons à justifier le blocage, qui peut théoriquement conduire à des problèmes dans les processus métier, ou nous vous conseillons sur les travaux qui doivent en partie être effectués de leur côté - blocage de compte, isolation de l'hôte, etc.
Mais la majorité préfère toujours s'engager seule dans une réponse technique et exige de nous la détection rapide d'un incident, l'analyse et le filtrage des faux positifs, ainsi que la fourniture d'informations analytiques avec des recommandations sur les actions prioritaires en réponse à un incident.
Qui était auparavant impliqué dans ce processus et était responsable du résultat de la part du client? En règle générale, un ou deux spécialistes de la sécurité de l'information qui combinaient le travail de réponse avec d'autres tâches du service et n'avaient pas toujours une expertise de niche approfondie dans l'analyse des attaques (comme vous pouvez le voir dans le paragraphe précédent, cela n'était pas nécessaire). Néanmoins, il a toujours été question de spécialistes de la sécurité de l'information qui comprennent les risques, les menaces et le contexte de ce qui se passe.
Récemment, la responsabilité de l'exhaustivité et de la rapidité de la réponse du côté du client est de plus en plus répartie entre la sécurité de l'information et les services informatiques, et voici pourquoi.
Premièrement, le nombre d'incidents et de soupçons d'incidents a considérablement augmenté. Si auparavant le nombre moyen de notifications était mesuré par un ou deux cents par mois, il a maintenant augmenté plusieurs fois. Une partie du problème est la croissance de l'entropie dans les infrastructures d'entreprise en raison des changements constants (et pas toujours fixes), qui sont causés par ce que l'on appelle maintenant communément le terme à la mode «numérisation» ou «transformation numérique». Un effet secondaire est que les actions des utilisateurs deviennent plus variées et que les solutions techniques sont plus susceptibles de les classer comme des anomalies de comportement, qui, à leur tour, peuvent être confondues avec un attaquant par un agent de sécurité. Ce sont des faux positifs, disons, du premier type.
Deuxièmement, l'activité des cybercriminels, bien sûr, est également en constante augmentation (en d'autres termes, le nombre d'attaques augmente), c'est ce que nous constatons, d'autres acteurs de l'industrie et les clients eux-mêmes. En conséquence, le SOC doit constamment inventer des scénarios de détection d'attaques de plus en plus astucieux et s'assurer de les connecter au client. Ceci, bien sûr, conduit également à une augmentation du nombre d'opérations, une augmentation du non-déterminisme des actions du client et le besoin d'informations sur l'incident pour contenir un contexte externe (à qui appartient le poste de travail, est-il habituel dans l'entreprise d'utiliser des outils d'accès à distance, et si oui, lesquels, qui ils peuvent être utilisés pour quoi, etc.).
En fait, cela conduit au fait que pour accélérer le processus de réponse, de plus en plus d'entreprises tentent de transférer le SOC externe vers une interaction directe non pas avec la sécurité de l'information, mais avec les services informatiques. Et cela est tout à fait logique: les incidents nécessitant la suppression de logiciels ou le verrouillage de compte sont directement dirigés vers le service informatique, ce qui nécessite une isolation du réseau de l'hôte - vers les services réseau + le service d'assistance, etc. Si l'entreprise dispose de son propre centre de surveillance, elle est souvent obligée de transférer les déclencheurs du système SIEM vers l'informatique.
Cependant, tout changement dans le processus est le risque de le ralentir, le risque d'une information incomplète pour les parties et, in fine, une diminution de l'efficacité. Heureusement, la plupart des entreprises le comprennent, par conséquent (et parfois en raison d'exigences législatives - en particulier, sur la création de centres GosSOPKA), il y a maintenant une demande croissante pour vérifier le niveau réel de réponse - l'exhaustivité, la qualité et le calendrier des recommandations des services informatiques et de sécurité de l'information. entreprises.
Cependant, avant de mener des audits, il est nécessaire de donner aux personnes un outil pour arriver au résultat, c'est-à-dire que le SOC doit adapter les résultats de l'analyse de chaque incident pour un routage clair en informatique. Par essais et erreurs, nous avons compilé une liste d'exigences pour les informations d'incident envoyées au client.
Dans ces résultats de l'analyse de l'incident, le salarié responsable de la réponse technique doit être clairement identifié
Quels sont les pièges: afin d'identifier correctement un tel responsable, il est nécessaire d'identifier avec précision le lieu de l'incident - un service spécifique, la criticité de l'hôte, son affiliation commerciale, le type d'incident. Cela nécessite une immersion très profonde dans l'infrastructure du client au stade de l'inventaire (et surtout une mise à jour constante de ces données).
Les mêmes informations sont nécessaires pour déterminer la criticité d'un incident. Par exemple, la banque est prête à réagir beaucoup plus lentement à une infection virale d'une voiture dans une succursale de Magadan et avec l'aide d'un spécialiste local de la sécurité de l'information. S'il s'agit de l'AWP local de la KBR, l'incident nécessite une réponse et une implication immédiates, notamment du RSSI du client pour coordonner le risque, ainsi que des spécialistes du centre de communication sur le site pour isoler immédiatement l'hébergeur.
Répondre à une attaque contre une application Web dans le segment du commerce électronique nécessite en règle générale l'implication non seulement du personnel de sécurité, mais également des spécialistes des applications qui peuvent déterminer plus précisément les risques associés à sa mise en œuvre et décharger des informations sur les commandes de la base de données sur le même hôte, au contraire, elle ne doit en aucun cas impliquer ni des candidats (ils font partie des attaquants potentiels), ni même des informaticiens, mais en plus de la sécurité de l'information, elle nécessite souvent la participation du service de sécurité économique.
Tous ces scénarios - que nous impliquons quand, à quel stade et dans quel but - doivent être élaborés à l'avance et convenus avec le client. Le SOC connaît mieux la sécurité de l'information, mais le client connaît mieux son entreprise et les risques les plus critiques pour lui, de sorte que les scripts sont développés ensemble.
Cela s'applique également à la description de la menace et de ses risques, ainsi qu'au niveau de détail dans la description des recommandations d'intervention. De plus, idéalement, la séquence des actions requises devrait être divisée en un arbre d'événements obligatoires et auxiliaires. Par exemple, si le SOC enregistre le lancement de l'outil d'administration à distance sur l'hôte final, mais que le niveau d'audit n'est pas suffisant pour distinguer l'activité de l'utilisateur d'un éventuel lancement d'une porte dérobée par un attaquant, alors le premier point obligatoire sera la communication du spécialiste avec l'utilisateur pour savoir s'il a initié cette activité. Si la réponse est oui, il s'agit d'une activité régulière ou, au maximum, d'une violation de la politique de sécurité de l'information. S'il est négatif, il peut faire partie d'une attaque de pirate informatique et nécessite un travail de réponse complètement différent.
La vérification des résultats de la réponse doit contenir la possibilité d'un contrôle technique à la fois du fait de la mise en œuvre des recommandations (à l'aide de logs dans SIEM ou d'autres outils), et du fait que l'incident ne se reproduira plus dans le futur.
Continuons l'exemple avec l'exécution de RAT sur l'hôte. Par exemple, nous sommes allés à la première branche - activité des utilisateurs qui enfreignait les politiques de sécurité des informations. Dans ce cas, il sera conseillé au service informatique de supprimer le RAT sur l'hôte. En plus du lancement contrôlé du script de suppression ou de la vérification de l'absence / présence d'un utilitaire sur l'hôte, les outils d'inventaire doivent être liés à l'ancien incident lorsqu'il est redéclenché. Cela signale non seulement une violation répétée, mais aussi une possible mise en œuvre de mauvaise qualité de la recommandation par la réponse.
Enfin, le contexte ou le voisinage delta de l'incident est important. Il est très important de savoir ce qui est exactement arrivé à cette machine / compte au cours du dernier intervalle de temps, s'il y a eu des incidents similaires ou potentiellement liés qui pourraient être collectés dans la chaîne de destruction. Ces informations vous permettent de déterminer rapidement si vous devez immédiatement impliquer l'équipe de sécurité ou de réponse aux incidents du fournisseur dans l'incident.
Chaque SOC cherche ses propres réponses à ces défis et peut effectuer ces tâches à l'aide de différents outils, l'essentiel est de contrôler qu'il le fasse en principe. Parce que sur les incidents mineurs, les retards et les hésitations de réponse peuvent être imperceptibles, et sur les incidents critiques, un processus non réglementé ne fonctionnera tout simplement pas. Et c'est comme s'il n'y avait pas de coupables.