Certes, et je suis le premier à le dire, maîtriser totalement les flux entrant et sortant de vos infrastructures et environnements, c’est se protéger contre des vecteurs et méthodes d’attaques bien connus, anciens… et toujours terriblement efficaces (reverse shell, connexion à des serveurs Command & Control…). Mais il est impossible de construire une bulle isolée de tout car cela va à l’encontre même de l’essence même d’un système d’information, qui doit pouvoir être accessible.
Mon point est justement le suivant : les équipes réseaux qui sont généralement en charge des mécanismes de défenses périmétriques, ne sont pas là pour mettre en œuvre les mécanismes de défense nécessaires sur les serveurs et postes de travail. Il n’est également pas dans leurs attributions de maintenir à jour les systèmes d’exploitation, binaires et librairies présentes.
L’infrastructure peut permettre d’isoler tout ou partie du système d’information, mais ne pourra généralement rien si un malware, par exemple de type « ransomware » (logiciel malveillant d’extorsion), se propage à l’ensemble des terminaux de vos utilisateurs ou entre vos différents environnements si ceux-ci ne sont pas correctement segmentés. Et ceci n’est qu’un petit aperçu des limites de la défense périmétrique.
Il est également nécessaire de garder en tête que, pour une équipe réseau, analyser les logs de sécurité n’est pas nécessairement trivial. Prenez une alerte générée par un NIDS/NIPS (Sonde de détection/ prévention d’intrusion), un WAF (firewall applicatif web) ou autre, et essayez de définir s’il s’agit d’un faux positif, ou d’une alerte légitime. Et si cette alerte est une simple tentative qui a échoué, ou la trace d’une attaque réussie…
Clairement, analyser ces traces est un métier à part et nécessite généralement de combiner des connaissances en réseau, système, technologie web et en cybersécurité. Ainsi, la sécurité est et restera un domaine transverse et pluridisciplinaire qui a besoin d’une approche globale, en utilisant de manière coordonnée les différents mécanismes de défense existants.
Ne vous méprenez pas, je ne prétends pas qu’un ingénieur réseau ne pourra jamais devenir un analyste sécurité efficace, ayant moi même un passé réseau, mais que cela ne suffira pas dans ses tâches quotidiennes, et sur des systèmes dont il n’a pas nécessairement la connaissance car hors de son périmètre et de sa qualification technique.
Au final, l’important sera de coordonner les compétences de chacun, pour les faire travailler ensemble sur le traitement des incidents de sécurité, et l’amélioration continue des mécanisme de protection et de détection. Et si vous avez besoin d’aide pour mettre en place cette organisation, iDNA est là pour vous épauler.