Passer au contenu principal
Explications

Integrating Tanium and SCCM: Client Health

Dans le cadre de mes fonctions chez Tanium, je suis régulièrement confronté à des environnements informatiques complexes. La situation de chaque client est véritablement unique ; cependant, l’un des aspects remarquables de Tanium réside dans sa capacité à s’adapter et à fonctionner de manière optimale au sein de réseaux d’entreprise chaotiques. L'un des aspects de ce type de complexité réside dans la diversité des solutions de sécurité et de gestion existantes qui sont déployées.

Même si Tanium peut, à terme, contribuer à réduire le nombre de solutions cloisonnées, de nombreux produits font partie intégrante des pratiques et des processus existants, ou répondent tout simplement à des cas d'utilisation que Tanium ne couvre pas. Même en considérant Tanium comme une plateforme de sécurité et de gestion, les responsables informatiques doivent tout de même se poser la question suivante : « Comment puis-je optimiser les capacités de mon système actuel tout en réduisant mes effectifs en équivalents temps plein et mon coût total de possession ? » Heureusement, Tanium ne se contente pas de coexister avec de nombreuses solutions existantes, mais peut en réalité les compléter et les rendre plus efficaces.

L'une de ces solutions est le System Center Configuration Manager (SCCM) de Microsoft, actuellement utilisé par un certain nombre de clients de Tanium. Je dispose d'une vision unique chez Tanium après avoir occupé pendant près de 15 ans des postes dans les domaines de l'exploitation, de l'intégration et du conseil, en utilisant SCCM. Même si certains peuvent être tentés de comparer SCCM et Tanium, ce n’est pas tout à fait la même chose. Il existe des domaines dans lesquels Tanium présente des avantages que SCCM n'offre pas, et inversement. Dans le cas de SCCM, les intégrations avec Tanium améliorent en effet l'expérience : elles permettent de réduire la surface d'attaque, de détecter les menaces en temps réel et de réduire les coûts grâce à une meilleure connaissance des applications inconnues et potentiellement vulnérables.

Lorsque les processus de gestion du changement ne donnent pas les résultats escomptés

Aujourd'hui, nous allons nous intéresser aux systèmes dans lesquels la communication avec la direction fait défaut. Il peut y avoir de nombreuses raisons à cela, mais je vais ici aborder un problème lié aux personnes et aux processus. D'après mon expérience, les environnements SCCM comptent souvent entre 5 et 20 % de clients inexistants ou défaillants ; d'innombrables organisations disposent de systèmes qui ont déjà « disparu » au bout de 6 mois, voire d'une année, après leur déploiement initial. Combien de fois vous est-il arrivé, lors du dépannage d'un déploiement, d'un correctif ou de toute autre opération, de constater qu'en raison d'une modification du réseau, vous vous retrouviez avec un nouveau sous-réseau sans limites définies dans SCCM, mais comportant de nombreux clients ? (Ceci n'est en aucun cas une critique à l'égard des ingénieurs réseau, mais, de par la nature même de ce secteur d'activité, la gestion du changement n'est pas toujours correctement communiquée.) Je suis sûr que cela est déjà arrivé à tous les administrateurs SCCM qui exercent ce métier depuis suffisamment longtemps. Et pour ceux qui n’ont pas encore vu cela, j’espère qu’une idée vient de vous traverser l’esprit et que vous vous empressez d’aller régler ce problème récurrent de communication avec les clients dans un certain lieu. Je serai toujours là à votre retour.

Ce problème est inévitable, surtout à grande échelle. Même lorsque les processus de gestion du changement sont correctement respectés, le niveau de transparence finit par créer une certaine confusion en raison du bruit ambiant, et certains éléments passeront inaperçus (notamment un changement standard tel que la mise en service d'un nouveau sous-réseau). Quelle qu'en soit la cause, cela entraîne la perte immédiate d'une partie de vos clients SCCM. Malheureusement, SCCM ne dispose d'aucune notification intégrée ; il est donc difficile – voire pratiquement impossible – de gérer ce risque de manière proactive, et le risque inhérent de le découvrir lors d'un déploiement à grande échelle augmente de manière exponentielle.

C'est là que Tanium entre en jeu. En quelques secondes, vous pouvez saisir la question suivante et savoir immédiatement quels sous-réseaux ne sont pas correctement gérés par SCCM :**

Récupérer le sous-réseau du client Tanium à partir de toutes les machines dont la durée de communication du client SCCM est supérieure à 1 jour

Cela vous permet d'obtenir immédiatement le nombre de tous les systèmes de chaque sous-réseau qui n'ont pas communiqué avec SCCM depuis plus d'un jour. Il ne faut alors que quelques minutes pour résoudre le problème en ajoutant les périmètres et/ou les groupes de périmètres appropriés dans SCCM et en définissant les sites et les points de distribution. Même si vous pensez ne pas être concerné par ce problème, essayez tout de même et posez la question ci-dessous dans votre console Tanium. Vous serez surpris de ce que vous découvrirez et de ce que vous pourrez facilement corriger.

Si un sous-réseau donné comporte un nombre élevé d'adresses, il y a de fortes chances que ce sous-réseau ne soit pas défini dans SCCM. Par défaut, les clients SCCM doivent effectuer une vérification des stratégies toutes les 60 minutes ; par conséquent, s'ils n'ont pas communiqué depuis plus d'une journée, cela signifie qu'il y a un problème. Comme Tanium analyse les clients actuellement connectés, les résultats ne sont pas faussés par des données obsolètes provenant de systèmes hors ligne. Un simple script PowerShell (utilisant les cmdlets PowerShell de SCCM 2012 ) pourrait récupérer les sous-réseaux identifiés dans Tanium et les comparer à ceux des groupes de périmètre au sein de SCCM ; vous obtiendriez ainsi les plages manquantes.

Une autre approche possible pour résoudre ce même problème consisterait à poser la question suivante dans Tanium afin d'obtenir le nombre total de clients dans chaque sous-réseau :

Récupérer le sous-réseau du client Tanium à partir de toutes les machines

Si le nombre de terminaux d'un sous-réseau indiqué dans la première question correspond à celui indiqué dans la deuxième question, cela signifie que vous avez identifié une limite non gérée dans SCCM, car cela indique que tous les clients en ligne de ce sous-réseau ne communiquent pas avec SCCM. Là encore, une fois le problème identifié à l'aide de Tanium, sa résolution ne prend que quelques minutes dans la console SCCM.

Ajoutez ces deux questions à un tableau de bord, ou ajoutez même une question enregistrée associée à une alerte via Tanium Connect afin d'être averti si une telle limite est détectée ; vous aurez ainsi rapidement résolu un problème majeur en matière de couverture des clients SCCM.

Pourquoi est-ce important ? En effet, SCCM est un outil couramment utilisé par les entreprises pour la distribution de logiciels et de mises à jour. Si vous perdez quelques centaines ou quelques milliers de terminaux, ces actifs ne seront ni répertoriés ni gérés. Il en résulte que les équipements ne bénéficient pas des correctifs nécessaires et que des appels au support technique sont effectués pour signaler l'absence d'installations logicielles demandées, ce qui engendre des heures de travail pour une cause première pourtant si simple. Les malfaiteurs n'attendent pas que vous remarquiez les failles de votre environnement, alors pourquoi devriez-vous le faire ? En mettant en pratique ce cas d'utilisation simple, vous réduirez les risques et le nombre d'heures de travail, tout en contribuant à offrir une meilleure expérience utilisateur, et ce, tout en laissant ce casque de pompier dans le tiroir un peu plus longtemps.

À propos de l'auteur : Greg Thomas apporte une vaste expertise à son poste de directeur de la gestion technique des comptes chez Tanium, notamment dans les domaines de la création de scripts, de l'automatisation des processus, ainsi que de la conception, de l'administration et de la maintenance d'Active Directory et de SCCM. Avant de rejoindre Tanium, Greg a conçu, mis en œuvre et assuré le support de solutions techniques dans les secteurs public et privé en tant qu'ingénieur-conseil.