GosSOPKA signifie. Traduire la terminologie

Si vous travaillez pour une entreprise qui relève de l'action n ° 187-FZ («Sur la sécurité de l'infrastructure d'information critique de la Fédération de Russie»), vous n'avez pas besoin d'expliquer ce qu'est GosSOPKA et pourquoi il est nécessaire. Pour le reste, nous expliquons: GosSOPKA signifie système d'État pour détecter, prévenir et éliminer les conséquences des attaques informatiques. Sur le plan architectural, il s'agit d'un complexe unique de centres de différentes tailles, géographiquement répartis, échangeant des informations sur les cyberattaques. Ces centres sont nécessaires pour créer toutes les entreprises qui possèdent les objets de l'infrastructure d'information critique (ces entreprises sont appelées sujets de CII). Le but de cette initiative gouvernementale à grande échelle est de créer un système d'échange d'informations entre les organisations les plus importantes du pays sur les cyberattaques en cours et ainsi offrir la possibilité d'une protection préventive.

Pendant longtemps, le principal document définissant les principes de fonctionnement des centres GosSOPKA et leur interaction avec un centre supérieur ont été les «Recommandations méthodologiques pour la création et le fonctionnement des centres GosSOPKA» élaborées par le FSB. Nous avons précédemment examiné ce document et noté que le principal objectif de son attention était la construction de processus de gestion des incidents et de contrôle de sécurité des sujets GosSOPKA. Mais en même temps, cette approche a laissé un champ assez large pour différentes interprétations de la quantité de tâches que le centre GosSOPKA devrait résoudre et des outils spécifiques nécessaires pour cela. Récemment, "Exigences pour les outils conçus pour détecter, prévenir et éliminer les conséquences des attaques informatiques et pour répondre aux incidents informatiques." Essayons de comprendre ce que le régulateur attend des entreprises qui construisent leurs propres centres GosSOPKA et d’enquêter sur ce problème.


Hiérarchie d'interaction des centres

Il existe des tentatives connues pour construire des centres GosSOPKA exclusivement sur des systèmes IDS. Il existe également sur le marché des fournisseurs qui positionnent IDS ou SOA comme une solution universelle au problème. Les sujets de KII avaient de nombreuses questions concernant la fonctionnalité et les exigences des systèmes SIEM, que de nombreuses entreprises considéraient comme le seul outil nécessaire pour créer un centre GosSOPKA.

Maintenant, avec l’arrivée du document «Exigences pour les outils conçus pour détecter, prévenir et éliminer les conséquences des attaques informatiques et répondre aux incidents informatiques», la première clarté apparaît concernant les exigences réelles du régulateur pour les outils du centre.

Le document décrit cinq sous-systèmes principaux du centre GosSOPKA:

1. Outils de détection
2. Moyens d'avertissement
3. Outils de liquidation
4. Outils de déchiffrement (PACA)
5. Outils d'échange d'informations
6. Moyens de protection cryptographique des canaux de communication

Essayons de parcourir chacun des éléments de manière séquentielle. Nous ferons tout de suite une réservation pour ne pas tenir compte des problèmes d '«orthodoxie» du produit et de la nécessité de remplacer les importations, nous nous concentrerons exclusivement sur les aspects techniques.

Des outils de détection, mais pas SOA. Quatre lettres

À notre avis, ce point est l'un des plus importants du point de vue du règlement des différends sur les moyens qui peuvent être utilisés, car les discussions "Avez-vous besoin de SIEM, ou simplement de suffisamment de sous-systèmes SOA" sont en cours et ne disparaissent pas.

Lisons le document plus en détail:

Tout d'abord, nous parlons d'un outil qui recueille les événements de sécurité de l'information. Pas d'incidents (les résultats du travail des équipements de protection), pas le trafic brut ou sa copie, à savoir les événements. Cela nous donne une indication assez transparente que nous avons besoin d'une fonctionnalité de traitement des journaux.

La note de ce paragraphe fournit également une liste assez détaillée et large des sources potentielles qui devraient donner ces événements. La liste comprend non seulement les moyens de protection classiques (pare-feu, SOA, antivirus), mais aussi les sources d'infrastructure (équipements réseau et systèmes d'exploitation), ainsi que les systèmes de gestion des applications pour les équipements réseau, les systèmes de surveillance de la qualité de service, etc.

Tout cela, ainsi que les mots «corrélation et agrégation d'événements» mentionnés dans les exigences fonctionnelles, à notre avis, définissent assez précisément la technologie cible de l'article en tant que plate-forme SIEM .

Cela suit pleinement les recommandations méthodologiques émises précédemment, car pour détecter pleinement les incidents informatiques des catégories «accès non autorisé», «devinette de mot de passe» et «malware», un moyen de protection actif ne sera pas suffisant.

Est-ce qu'une plate-forme commercialisée comme SIEM conviendra également? À notre avis, non, car au moins deux exigences assez importantes sont indiquées dans le texte:

• Le système de détection doit non seulement corréler et détecter les incidents, mais également enregistrer les résultats de leur traitement et «les informations sur les événements SI, y compris dans leur forme d'origine». Compte tenu de la liste de sources ci-dessus, ainsi que de la profondeur de stockage recommandée (au moins 6 mois), nous parlons d'une plate-forme à part entière avec une fonctionnalité avancée de gestion des journaux et de la volonté de gérer des flux d'événements très importants. Cela réduit considérablement la liste des options potentielles.
• Le système de détection devrait avoir «un support intégré pour diverses sources d'événements de sécurité de l'information et la capacité de développer des modules supplémentaires qui fournissent des informations à partir de nouvelles sources d'événements de sécurité de l'information», c'est-à-dire la capacité d'affiner rapidement la liste et la composition des sources connectées. Cela impose des exigences sur la disponibilité d'une API ouverte pour le développement de telles méthodes de connexion (dans l'argot SIEM - connecteurs) ou sur la capacité à obtenir rapidement un tel raffinement auprès du fournisseur.

Intégralement, ces exigences démontrent une attitude très sérieuse du régulateur vis-à-vis de la fonctionnalité du système de détection. À mon avis, ils indiquent indirectement que l'exécution formelle des recommandations méthodologiques (par exemple, «les incidents de logiciels malveillants peuvent être détectés par le trafic réseau, nous n'avons pas besoin d'un antivirus» ou «nous devons simplement connecter seulement deux sources pour répondre aux exigences») ont peu de chances d'avoir le droit à l'existence. Une étude sérieuse du modèle de menace et des travaux sur la mise en place de scénarios de surveillance seront nécessaires.

L'avertir ou l'inventorier

La section suivante - les moyens d'avertissement - est beaucoup plus proche et plus compréhensible pour le gardien de sécurité à la fois en termes et en approches. Les fonctions suivantes sont affectées aux moyens d'avertissement:

• Inventaire des actifs d'infrastructure avec la capacité de stocker et de compléter les informations.
• Collecte et évaluation d'informations sur les vulnérabilités des ressources d'information.
• Collecte et évaluation d'informations sur les lacunes (dans notre lecture - erreurs de configuration) des ressources d'information.

La liste des fonctions décrites est le plus souvent implémentée par des produits logiciels de la classe Vulnerability Scanner ou des scanners de sécurité. Il semblerait que le nom non évident «système d'alerte» porte une logique très correcte: il est impossible d'empêcher un vecteur d'attaque potentiel et d'identifier les points faibles de l'infrastructure si vous ne disposez pas d'informations complètes sur son état, les nœuds utilisés, le logiciel ou les vulnérabilités des processus de vos actifs.

La tâche de gestion des actifs et des vulnérabilités, avec toute sa simplicité apparente, est semée d'embûches. Mais une discussion de ces détails ne fait pas partie du matériel actuel et pourrait apparaître dans nos futurs articles. Je veux juste noter que presque toutes les entreprises sont équipées des outils nécessaires pour résoudre le problème, car des exigences similaires sont déjà apparues dans différents ordres et ordonnances du FSTEC, et même dans la loi sur les données personnelles. La tâche clé est de «faire revivre» un outil existant et de démarrer des processus dans la réalité, et non sur papier.

L'élimination comme élimination collaborative

Ici, le nom du produit et ses exigences ont reçu une interprétation plutôt inattendue. Comme moyen d'élimination, nous avons une solution proche de la plate-forme de gestion des incidents, qui dans le monde informatique s'appelle le service desk, et l'IB se réfère fièrement à la plate-forme de réponse aux incidents (bien que l'IRP ait également des fonctionnalités spécialisées). En fait, les tâches principales du sous-système sont:

• Enregistrement d'incident avec possibilité de modifier et de compléter la carte d'incident.
• La capacité à gérer son cycle de vie avec le transfert de l'incident entre le responsable et les unités.
• La possibilité de récupérer la carte d'incident finale conformément aux formats approuvés par le SCCC.

Sur cette base, la correspondance de la fonction avec le nom du système est également construite. La liquidation d'un incident nécessite principalement l'interaction de différents services de l'entreprise, et la gestion du processus de liquidation, le contrôle de son calendrier et de son exhaustivité dans ce cas, sont mis en avant. Par conséquent, le centre GosSOPKA, en tant que responsable de ce processus, devrait disposer des outils appropriés.

Le choix des solutions et technologies créées spécifiquement pour les tâches SI sur le marché est encore très limité. Mais le document ne contient pas de restrictions directes sur l'utilisation à cette fin d'un système informatique commun (de conception standard ou individuelle) avec quelques modifications pour les tâches SI. En règle générale, les systèmes de centre de services sont un constructeur bien personnalisable, donc la révision ne devrait pas être difficile.

Autres installations du centre

Les fonctions et les tâches du sous-système PACA visent principalement à analyser le trafic réseau, à la fois en mode temps réel (afin de détecter les attaques ou tentatives d'accès non autorisé aux équipements réseau), et à enregistrer et stocker le trafic réseau en vue de son utilisation ultérieure en rétrospective. analyse des événements ou enquête sur l'incident. Ces exigences ne sont pas fondamentalement nouvelles. L'enregistrement du trafic réseau a été confié à tous les propriétaires de systèmes d'information étatiques depuis 2010 dans le cadre d'un arrêté conjoint du FSTEC et du FSB. Ces exigences peuvent être inattendues pour les entreprises commerciales, mais en fait leur mise en œuvre n'est pas non plus particulièrement difficile.

Les exigences relatives aux sous-systèmes d'échange et à la protection cryptographique des canaux de communication sont également assez familières et ne nécessitent probablement pas d'explications supplémentaires.

En résumé, la publication de ce document a mis beaucoup de points sur moi concernant les outils et technologies qui doivent équiper le centre de GosSOPKA. Désormais, chaque client dispose d'une liste formelle d'exigences, qui est utile à la fois pour comparer les fournisseurs et pour décider de l'achat / du remplacement de la technologie. Et l'apparence de clarté dans ces domaines affecte toujours positivement l'efficacité et la rapidité des mesures prises par des acteurs spécifiques pour se connecter, ainsi que la sécurité globale des infrastructures d'information critiques.