Les 5 meilleurs tickets de support réseau à automatiser
Qu'est-ce qui vous frustre le plus dans le support réseau ? Rien de mieux que de jouer au détective sur un problème de réseau obscur et d'être le héros informatique qui le résout. Mais trop...
Se pencher sur les journaux de sécurité pendant des heures et des heures n'est pas une façon de passer un après-midi, mais c'est le seul moyen de vraiment comprendre ce qui s'est passé lors d'un incident de sécurité. Se connecter à un appareil à la fois est le seul moyen de savoir pourquoi et comment le trafic a été bloqué quelque part sur le réseau, mais je ne ferais pas confiance aux résultats.
Les informations de journalisation, la découverte du réseau et une compréhension en temps réel de l'état du réseau sont si importantes pour la sécurité du réseau que nous collectons de grandes quantités de données à partir de plusieurs de nos systèmes dans le but de suivre et de mémoriser tout ce qui se passe sur nos réseaux. Le collectionner est une chose, mais le rendre utile en est une autre.
La configuration des traps SNMP et des serveurs syslog n'est pas très difficile. Cependant, être capable de trouver l'aiguille proverbiale dans la botte de foin peut être si fastidieux et coûteux que les services informatiques renoncent souvent à l'investigation du réseau. Nous voulons des journaux volumineux, et souvent nous sommes conditions d'avoir des journaux étendus. Mais tout aussi souvent, ces journaux restent inutilisés, inexploités et donc dénués de sens.
Un flux de travail typique pour un incident de sécurité peut consister à créer l'incident dans le système de billetterie, à joindre la chaîne d'e-mails pertinente au ticket, à copier un lien vers le serveur de journalisation, puis à fermer le ticket. Il n'y a pas grand-chose d'autre à faire et peu de temps pour faire quoi que ce soit de toute façon. Au moins de cette façon, c'est dans le système et le service informatique est en conformité.
L'investigation réseau est extrêmement importante, mais elle est extrêmement coûteuse en raison des compétences nécessaires et du temps nécessaire. Comment collectons-nous des données spécifiques à partir de chaque appareil, quelle que soit la plate-forme ? Comment pouvons-nous nous assurer qu'il s'agit d'informations exactes ? Et que faisons-nous de toutes ces données une fois que nous les avons collectées ? La sécurité du réseau est importante, mais la sécurité du réseau n'est pas une configuration de commutateur ou un modèle de pare-feu. C'est tout un processus, et ce n'est pas facile.
Je me souviens qu'un fournisseur m'a demandé qui dirigeait notre équipe de sécurité informatique. Je lui lançai un regard vide. D'après mon expérience, seules les très grandes organisations disposaient de personnel dédié à la sécurité informatique, sans parler d'équipes entières. J'ai répondu que nous avions un département de quelques dizaines de personnes et que la sécurité était principalement gérée par les gens du réseau puisque la sécurité, pour nous, concernait les pare-feu, les appliances IPS, le 802.1x et d'autres technologies de réseau.
Mais nous savons que la sécurité du réseau est bien plus que cela. C'est une question de visibilité. Il s'agit de la capacité d'identifier un comportement anormal, et de la capacité de suivre rapidement où et comment le trafic est bloqué dans un réseau de production. Les ingénieurs réseau peuvent connaître toutes les commandes pour configurer la journalisation sur chaque plate-forme de leur environnement, et nous pouvons savoir comment configurer une ACL pendant notre sommeil. Cependant, le processus d'utilisation de ces connaissances et informations à grande échelle peut être plus coûteux que l'incident de sécurité lui-même.
Nous avons ici un exemple très pratique de la façon dont les tendances actuelles en matière d'automatisation du réseau peuvent aider le résultat net d'un service informatique typique aux prises avec des budgets, du personnel et la lutte contre les incendies au quotidien. Je connais un peu les scripts Linux de base et un peu Python. Cela aiderait, et ce sont certainement de bonnes compétences à acquérir. Mais la réalité est que j'ai toujours été un routeur jockey. je ne suis pas DevOps gourou, et je soupçonne que la plupart des ingénieurs réseau ne le sont pas non plus. Alors, comment pouvons-nous facilement tirer parti des aspects de la DevOps paradigme tel que l'automatisation des processus, un délai moyen de récupération plus rapide, l'assurance qualité et la livraison continue ?
La voie la plus simple et la plus rapide pour y parvenir est d'abstraire les processus de script et d'automatisation derrière un logiciel intuitif. De cette façon, les ingénieurs réseau ayant une connaissance minimale des scripts peuvent automatiser la collecte de toutes sortes d'informations qui nécessiteraient souvent de se connecter individuellement aux appareils et d'exécuter les commandes appropriées.
Par exemple, pour une analyse de sécurité réseau pour un client, je voudrais savoir exactement quels types d'ACL sont déployés sur l'ensemble du réseau. Cela signifie que je devrais examiner chaque interface de couche 3 dont ils disposent. Dans un grand réseau, il y a probablement de nombreux appareils avec des terminaisons de couche 3, donc cela prendrait tellement de temps et serait si sujet aux erreurs que les résultats ne sont pas fiables.
Un logiciel mature qui résume ce processus serait un outil incroyable entre les mains de tout ingénieur en sécurité. Tant qu'il est quelque peu personnalisable et fonctionne avec une variété de plates-formes majeures, cela réduirait le temps et le coût nécessaires pour effectuer un audit de sécurité et une analyse post-portem. Cartographier toutes les interfaces de couche 3 et les ACL configurées sur celles-ci serait une question de quelques clics de souris.
En plus de pouvoir cartographier dynamiquement les topologies de couche 3, ce type de logiciel doit cartographier visuellement la couche 2 afin d'identifier les ports bloqués par Spanning Tree et parcourir les tables ARP et MAC. C'est incroyablement fastidieux et chronophage à faire manuellement, et à moins qu'une équipe réseau ait le luxe du temps et de plusieurs DevOps ingénieurs, cela ne serait probablement même pas tenté dans le cadre d'une enquête de sécurité réseau typique.
Se pencher sur les journaux de sécurité et se connecter manuellement à chaque appareil d'un réseau n'est pas une façon de passer un après-midi, mais il existe un meilleur moyen. Un logiciel qui résume toutes les parties difficiles de l'automatisation du réseau peut rapidement transformer de grandes quantités de fichiers journaux en données significatives et exploitables et identifier dynamiquement les zones problématiques dans une mer d'Ethernet. Aujourd'hui, l'aiguille proverbiale dans la botte de foin devient beaucoup plus facile à trouver sans ruiner votre budget informatique pour l'année prochaine.