Pour que l'analyse soit substantielle, nous fixons d'abord que nous comparons le SOC OT avec la structure du centre de surveillance, qui est implémentée dans notre Solar JSOC.
Entre autres, il nous permettra de discuter de ces différences dans le cadre des missions du centre GosSOPKA, également responsable des segments industriels.
Des détails sur chaque niveau du modèle peuvent être trouvés dans les articles précédents sur l'inventaire de l'infrastructure , la surveillance , les renseignements sur les menaces ( 1 , 2 ), le contrôle de la sécurité , le personnel et les processus.... Dans l'article actuel, nous nous concentrerons sur le bloc central de la surveillance de la sécurité (les caractéristiques des processus de réponse et d'enquête dans le système de contrôle de processus automatisé seront dans d'autres articles).
Le théâtre commence par un cintre et le SOC commence par la surveillance
Il semble que dans le domaine de la surveillance des événements, de la corrélation et de la détection des incidents, tout est déjà défini et connu. Et même combler le vide d'air pour recueillir les événements de sécurité est un sujet assez éprouvé . Mais, néanmoins, il y a quelques nuances qui méritent vraiment d'être prises en compte.
Architecture générale du SOC... Malgré la solution apparemment simple avec un intervalle d'air, la situation pour les grandes entreprises fédérales avec des installations distribuées (cela est particulièrement vrai pour l'industrie de l'énergie) est plutôt compliquée. Le nombre d'objets est mesuré en milliers, souvent il n'est même pas possible d'y placer un serveur de collecte d'événements, chacun des objets est assez compact, mais peut générer des événements de sécurité de l'information importants. Même en plus de la situation décrite, le problème des canaux de communication est souvent superposé, si étroit qu'au moins une charge significative sur la transmission des événements au "centre" commence à interférer avec le fonctionnement des applications principales.
Par conséquent, comment décomposer correctement les composants SIEM par sites est une question très sérieuse. Nous y reviendrons dans l'un de nos autres documents, car
Spécialisation et profilage de cas d'utilisation . Même sans aborder le sujet des scénarios complètement spécialisés qui ne sont pertinents que pour le segment ICS, il convient de noter que même les incidents standard dans l'ICS ont une signification et une criticité complètement différentes. Nous sommes tous habitués à utiliser les outils d'administration à distance sur un réseau d'entreprise. Mais il est évident que la criticité d'un tel incident, ainsi que, en principe, d'une communication réussie avec Internet dans un réseau technologique fermé, est énorme. Il en est de même pour l'installation d'un nouveau service système sur un poste de travail technologique, le fait de détecter des malwares nécessitant une investigation obligatoire, etc.
Des restrictions importantes sur l'utilisation de Use-Case sont introduites par des restrictions sur la mise en œuvre des systèmes de sécurité de l'information (généralement, les segments technologiques ne sont pas très riches en eux), et l'utilisation de versions obsolètes et héritées des systèmes d'exploitation (et les technologues regardent l'installation de Sysmon avec méfiance).
Néanmoins, un très grand volume de cas d'utilisation de l'environnement d'entreprise peut être appliqué avec succès au segment ICS et fournir un niveau suffisamment élevé de contrôle global de l'infrastructure.
Eh bien, il est difficile de passer devant le Saint des Saints - Systèmes SCADA... Si au niveau du système de sécurité de l'information, des systèmes d'exploitation et des flux réseau, tous les segments sont au moins légèrement, mais similaires, alors en allant plus loin, des différences clés apparaissent. En termes de réseaux et de segments d'entreprise, tout le monde rêve de veille commerciale et de connectivité applicative métier. Et ce processus, bien que complexe (les logs mutent et ne veulent pas se faire passer pour CEF, les informations normales ne peuvent être obtenues qu'à partir de la base de données, mais les administrateurs jurent et se plaignent du ralentissement), mais généralement mis en œuvre. Dans le segment technologique, lors de la connexion de systèmes de niveau supérieur et intermédiaire, ces problèmes sont élevés à un niveau absolu en relation avec la criticité spatiale des temps d'arrêt technologiques. Afin de faire les premiers pas pour connecter la source, vous avez besoin:
- Assemblez un stand et vérifiez le succès de la réception des événements
- Dessinez une solution architecturale générale avec tous les détails techniques
- Mettez-vous d'accord avec le vendeur dans quelques mois
- Revenez sur le stand du client avec émulation de charge de combat
- Très soigneusement (comme dans la blague sur les hérissons) pour implémenter la solution dans la production
Tristesse, désir, processus commerciaux. Et ceci malgré le fait que, en règle générale, l'équipement de l'APCS se caractérise par une journalisation suffisamment vaste, complète, compréhensible et de haute qualité.
Mais, heureusement (ou par coïncidence), une approche différente peut généralement être mise en œuvre dans les segments ICS. La plupart de leurs protocoles n'impliquent ni cryptage ni masquage des informations transmises. Par conséquent, l'une des approches les plus courantes pour la surveillance et l'analyse des commandes de contrôle est la mise en œuvre de systèmes de détection d'intrusion industriels ou de pare-feu industriels qui vous permettent de travailler avec une copie ou du trafic réseau réel et d'analyser les protocoles et les commandes de contrôle avec la journalisation ultérieure. Certains d'entre eux, entre autres, ont un moteur de corrélation de base intégré à l'intérieur (nous sauvant de l'horreur de la normalisation, de la catégorisation et du profilage des événements), mais en même temps, ils ne remplacent pas complètement le système SIEM.
, ,
Passer à autre chose. Il semblerait que les questions d'inventaire dans le réseau ICS soient les moins douloureuses. Le réseau est assez statique, l'équipement est isolé des segments communs, apporter des modifications à l'architecture nécessite tout un projet de travail. Un conte de fées sur les réseaux d'entreprise - "Il suffit de réparer le modèle et de le saisir dans la CMDB." Mais, comme d'habitude, il y a une nuance: pour le segment ICS, l'apparition de tout nouvel équipement est l'un des signes extrêmement importants d'un incident ou d'une attaque, et il doit être identifié sans faute. Et avec tout cela, les méthodes classiques d'inventaire (modes de fonctionnement économe des scanners de vulnérabilité) provoquent les allergies les plus sévères chez les technologues, et même chez le personnel de sécurité du système de contrôle automatisé des processus. Il n'est pas rare dans un réseau d'entreprise que même l'analyse d'inventaire en mode infructueux à un moment malheureux puisse "mettre" une application spécifique.Naturellement, personne n'est prêt à prendre de tels risques dans le système de contrôle de processus automatisé.
Par conséquent, le principal outil d'inventaire dans APCS (en plus du contrôle manuel) est les systèmes d'analyse du trafic réseau et les systèmes de détection d'intrusion industriels mentionnés précédemment. Chaque nouveau nœud, apparaissant dans le réseau, commence à communiquer avec ses voisins. Tant les méthodes que les protocoles de communication, la spécificité des paquets et les champs de service permettent non seulement de voir rapidement le nouveau «voisin», mais aussi de l'identifier clairement.
En revanche, le processus d'identification et de gestion des vulnérabilités est plus prudent. En règle générale, l'infrastructure est mise à jour et corrigée rarement et de manière très contrôlée; la liste des logiciels d'application et des équipements technologiques est fixe. Par conséquent, pour déterminer la liste et le statut des vulnérabilités actuelles dans le segment ICS, il suffit généralement de déterminer le versionnage du logiciel clé et de vérifier les bulletins des fabricants. En conséquence, nous nous éloignons du mode d'analyse agressif et de vérification logicielle pour les méthodes d'audit et d'analyse des versions techniques et manuelles d'un expert de l'industrie.
Le processus d'analyse ou d'identification des menaces est construit de la même manière. En règle générale, un modèle fixe unique est modernisé soit sur le fait d'une reconstruction critique de l'infrastructure (ajout de nouveaux nœuds, mise à jour de la version firmware des équipements critiques, etc.), soit lors de la révélation d'une nouvelle vulnérabilité pertinente pour l'infrastructure et / ou d'un nouveau vecteur d'attaque. Cependant, avec eux aussi, tout n'est pas si simple.
OT Threat Intelligence ou des réseaux isolés rêvent-ils d'indicateurs de compromis?
Les informations sur les nouvelles menaces et les vecteurs d'attaque pourraient-elles être inutiles? Je voudrais répondre immédiatement «non», mais essayons ensemble de comprendre l'applicabilité des données TI classiques dans le segment OT mature.
Les TI sont généralement des flux (flux de données) ou des IoC (indicateurs de compromission pour identifier des logiciels malveillants ou des outils de piratage spécifiques). Ils contiennent les caractéristiques suivantes:
- (IP-, URL, ), upload «» , . , , . , , «» .
- (MD5- , , / ..), / / . , . , , , , whitelisting, , . – «» . TI .
En conséquence, pour les attaques visant ICS, les informations sur le TTP, les tactiques et les approches des attaquants, ce qui est extrêmement rare sur le marché TI, et les tactiques et approches des attaquants face à une attaque, qui permettront d'adapter les mécanismes de défense et les approches pour surveiller et identifier les menaces dans le segment, gagnent beaucoup plus de poids.
Ces nuances et bien d'autres nous obligent à adopter une approche très sérieuse et réfléchie du processus de construction d'un tel SOC ou du choix d'un entrepreneur, ainsi qu'à réfléchir sérieusement à la stratégie de formation d'un OT SOC. S'il croise le SOC IT ou s'il fonctionne séparément, est-il possible de résoudre une sorte d'enrichissement mutuel et de synergie dans les processus, les équipes et les tâches. Dans notre prochain article, nous tenterons de mettre en évidence les différentes approches des équipes internationales face à cette problématique. Soyez en sécurité dans tous les aspects de votre infrastructure et de votre vie.