Compétences de natation synchronisées ou alignement des tâches de surveillance et de réponse
Comme vous le savez, l'animal le plus rapide du monde devrait être un mille-pattes: il a le plus de pattes. Mais le pauvre animal est vraiment gêné par la nécessité de synchroniser ses pas et ses activités. Une histoire similaire hante souvent la vie du SOC (Security Operation Center). Les analystes développent des scénarios, froncent leurs sourcils, proposent de nouvelles façons de détecter les attaques, et l'équipe d'intervention ne comprend souvent pas quoi faire de ces incidents (et la distance augmente si un SOC commercial externe se trouve sur la première ligne de barricades). Cet état de fait conduit généralement à deux situations extrêmes:
- SLA « , », , SOC, . , , - .
- – «» . , , . , , . - - , SOC , . , , .
Rappelez-vous le sage Yin Fu Wo, qui a demandé à son élève qui achetait un scanner de sécurité, que ferait-il alors des vulnérabilités découvertes? En suivant son exemple, je souhaite vraiment poser une question à l'équipe de réponse: que ferez-vous exactement et, surtout, à quelle vitesse allez-vous avec les incidents trouvés?
Les capacités du processus de réponse vous permettent «d'aligner» la liste des incidents en fonction de leur criticité interne. Par exemple, les communications sur les changements critiques dans les processus ou les attaques sur le Web peuvent être logiquement basculées vers un mode d'appel téléphonique avec la collecte immédiate d'une équipe d'enquête. Pour gérer le lancement de TeamViewer sur des machines de succursales non critiques, une analyse syntaxique de quelques heures est une option adéquate. Et il est tout à fait acceptable de soumettre un rapport sur les statistiques des infections virales une fois par jour - avant le café du matin et la fermeture «tapis» des problèmes, quand exactement il y a une guérison massive des virus, la suppression des logiciels interdits, la mise à jour du système d'exploitation, la fermeture des vulnérabilités, etc. Cela aidera à uniformiser sensiblement le rythme de surveillance et de réponse et à créer des règles du jeu transparentes et confortables tout au long du processus de gestion des incidents.
Astuce 1. Définissez vos priorités. Étant donné que vous ne serez certainement pas en mesure de tout gérer en même temps, déterminez quels types d'incidents sont vraiment critiques pour les activités de votre entreprise et fixez le délai requis pour leur résolution.
Analytics, analytics, encore plus d'analyses d'incidents
De nombreux SOC commerciaux, ainsi que des équipes de script, parlent très souvent et sérieusement de l'incroyable pourcentage de filtrage des faux positifs, en raison duquel les clients sont censés être informés non pas des soupçons d'incidents, mais uniquement des attaques (comme on dit: «Dans tout ce que je veux l'essence même »).
Périodiquement, cela génère des processus étonnants pour analyser et enquêter sur les incidents, par exemple les suivants:
- Sur la base de l'analyse du trafic réseau, le SOC a enregistré le lancement des outils d'administration à distance (RAT) sur l'hôte.
- , . – , RAT ( ) , .
- « ». SIEM .
Laissons de côté le fait qu'en cas d'attaque de hacker, connecter la machine après coup au niveau du journal n'est pas une action très délibérée. Un attaquant aurait pu simplement frotter tous les journaux nécessaires, et se connecter à une machine nouvellement compromise sous un compte avec des privilèges considérables pourrait entraîner des conséquences beaucoup plus graves que de le compromettre lui-même (en particulier pour les clients intrépides qui, fatigués de gérer les cases à cocher pour fournir des droits, donnez au compte des droits d'administrateur de domaine SIEM).
L'essentiel est que du point de vue du résultat, tout ce processus complexe de vérification par le SOC et le service de sécurité équivaut simplement à décrocher le téléphone et à appeler un utilisateur spécifique en lui demandant s'il a lancé la session RAT et pour quelle raison. En conséquence, la réponse elle-même peut être reçue plusieurs fois plus rapidement et le temps total consacré à l'enquête sur l'incident sera considérablement réduit. Étant donné que l'exécution de RAT sur une machine locale 98% du temps est faite par l'utilisateur (ce qui ne rend que les 2% restants plus significatifs), cette approche de réponse est beaucoup plus efficace.
2. , . , , « », , , .
, –
Il est impossible de ne pas aborder ici un sujet qui est souvent couvert dans l'élaboration des processus de suivi et de réponse - la question de l'inventaire et de la comptabilité des actifs. Le plus souvent, ils parlent d'actifs dans la clé de l'enrichissement de l'information: pour comprendre la signification d'un incident, il est important de savoir de quel type de nœud de réseau il s'agit, qui en est propriétaire, quel logiciel y est installé. Mais en termes de développement de playbooks, cette tâche prend un sens supplémentaire: le processus de réponse à un incident dépendra directement du type de nœud et de la partie du réseau dans laquelle il se trouve.
Prenons un incident assez basique: l'infection par le virus de l'hôte. Il a un poids et une criticité complètement différents en fonction de l'emplacement de cet hôte:
- – , ;
- VIP-, , – ;
- .
Les processus de réponse dans les entreprises industrielles nécessitent encore plus d'attention. Le même incident avec le lancement de RAT sur une machine acquiert des accents et une criticité complètement différents si un tel utilitaire est lancé là où, selon la logique, il ne peut pas être - par exemple, au poste de travail d'un opérateur de processus technologique. Dans ce cas, la mesure de réponse par défaut consiste à déconnecter et à isoler l'hôte, puis à découvrir les raisons de l'exécution de l'utilitaire et une éventuelle analyse détaillée de l'hôte pour détecter les signes de compromission potentielle par un attaquant externe.
Astuce 3. Faites un inventaire des actifs. Superposez différentes classes d'incidents sur des segments de réseau. Ainsi, vous n'obtiendrez plus un modèle linéaire, où le niveau de criticité d'un incident est déterminé uniquement par son type, mais une matrice de base personnalisée pour votre organisation, qui peut être améliorée et affinée au fil du temps.
Réponse réelle vs réponse parfaite
La situation décrite ci-dessus met en évidence la question clé: dans quelle mesure l'équipe interne est-elle prête à réagir pour garantir l'élimination des conséquences et des causes de l'incident? Revenons à l'exemple de l'infection d'une machine malveillante - le processus de réponse peut ressembler à ceci:
- Analyse du canal de pénétration des malwares (mail / web / lecteur flash)
- Obtention d'informations sur le malware lui-même - quelle famille, conséquences potentielles, présence d'utilitaires associés
- Identifier les indicateurs de compromission typiques d'un malware donné, rechercher des indicateurs sur les machines voisines (ceci est particulièrement important lorsqu'il n'y a pas de couverture complète des postes de travail et des serveurs avec protection antivirus et que les logiciels malveillants peuvent pénétrer avec succès l'un des hôtes découverts)
- Recherche de tous les utilitaires associés dans l'infrastructure et l'assainissement
Mais si cette approche est appliquée pour chacun des corps viraux de l'infrastructure et pour chaque infection, cela entraînera des coûts de main-d'œuvre très importants. Par conséquent, une approche équilibrée de la réponse est nécessaire ici, en fonction de divers paramètres externes:
- Le modèle d'actifs déjà évoqué et leur criticité
- Le comportement de la famille malveillante - les vers, en particulier ceux qui portent une charge potentiellement destructrice, nécessitent plus d'attention
- «Vieillesse» du virus et sa connaissance des laboratoires anti-virus
- Son appartenance à la boîte à outils de regroupement pertinente pour l'entreprise ou l'industrie
En fonction de tous ces paramètres, une décision peut être prise - de la suppression de base des logiciels malveillants d'une voiture ordinaire ou du rechargement d'un hôte critique à une procédure de réponse plus complexe impliquant des experts spécialisés.
Astuce 4. Ne soyez pas paresseux pour «affûter la hache». Des conditions supplémentaires permettent de clarifier la priorité et l'algorithme d'action lors de la réponse à un incident. Ils permettent non seulement d'effectuer plus complètement tout le travail nécessaire pour localiser l'incident et contrer l'attaque, mais aussi d'éviter des mouvements inutiles dans des cas plus simples.
Dis-moi qui est ton ami et je te dirai comment être
Eh bien, la profondeur de l'expertise de la part de l'équipe d'intervention est certainement importante dans le développement des playbooks. Au début de notre travail en tant que SOC commercial, toute notre communication a été construite à travers une personne dédiée au service de sécurité de l'information du client. Dans ce cas, nous avons parlé d'un employé, même jeune étudiant, avec une formation spécialisée, qui, répondant à divers incidents de temps en temps, accumule sa propre expertise et fait son travail de plus en plus efficacement.
Nous pouvons conditionnellement diviser les playbooks en deux types: technique et commercial. Le premier décrit le flux de processus lors du traitement d'un incident, et il est créé pour une équipe d'intervention d'un client réputé. Et le second est une description de la chaîne de services impliqués dans l'incident, et son consommateur est plutôt la hiérarchie. En conséquence, il est très important de «connaître votre public», sinon il y aura des «difficultés de traduction» associées à la compréhension et à l'interprétation.
Récemment, les clients ont de plus en plus inclus les services informatiques, les unités commerciales, les technologues ou même le service d'assistance directement dans le processus de réponse. Et cela conduit souvent à des incidents. Au début de la pandémie, plusieurs clients ont été forcés de façon inattendue (comme tout le pays) à transférer massivement leurs utilisateurs vers un accès à distance. Puisqu'il n'a pas été possible de mettre en œuvre rapidement le deuxième facteur d'authentification, ce qui suit a été convenu comme un schéma temporaire: chaque connexion privilégiée à distance était vérifiée par le service d'assistance via un appel téléphonique. En l'absence de rétroaction, la question a été transmise au propriétaire commercial du système, qui pouvait décider de continuer à travailler ou de bloquer le compte jusqu'à ce que les circonstances soient clarifiées - en cas de suspicion d'activité incohérente.Dans le manuel du helpdesk, nous avons détaillé les procédures pour appeler et rechercher les contacts du propriétaire de l'entreprise avec le plus de détails possible. Mais ils n'ont pas écrit ce que l'employé du helpdesk devrait faire lorsqu'il a reçu une commande pour verrouiller le compte (et le service avait ces droits). Et le tout premier test de l'incident a montré que, après avoir reçu une lettre avec le message "illégitime, blocage", le spécialiste du helpdesk a simplement fermé l'application sans effectuer aucun blocage.
Astuce 5. Restez simple. Il est extrêmement important de prendre en compte les spécificités des qualifications et de la «fluidité» des ressources dans l'équipe d'intervention et de décomposer le livret d'instructions de base avec degrés de liberté pour un spécialiste à un «alphabet» pas à pas pour les services externes.Développer un processus de réponse est une chose très créative pour chaque entreprise. Cependant, il est très utile de prendre en compte à la fois votre propre expérience et celle des autres. Et que le NIST soit avec vous.