Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Peter Smith, Netwrix : Les défis de l’audit IT

avril 2015 par Peter Smith, Regional Sales Manager Europe de Netwrix

Peter Smith, Regional Sales Manager Europe de Netwrix, l’opérateur fournisseur de solutions de contrôle des changements dans les annuaires, cherche à savoir pourquoi tant d’organisations et d’entreprises continuent à se battre pour savoir ce qui se passe sur leurs réseaux.

Pour beaucoup de départements de sécurité de l’information, l’audit de systèmes n’est pas une priorité quand il s’agit de protéger les réseaux contre les menaces grandissantes. Cet audit est réalisé souvent une fois par an, ou alors quand il s’est passé un évènement fâcheux. Mais maintenant, ces départements sont sous la pression constante des autorités de régulation, des responsables de la conformité et des Comités exécutifs.

L’audit IT cherche à savoir ce qui a changé sur l’administration de réseaux, qui l’a changé, quand et où. Cette information s’avère vitale, et devrait être une partie intégrale et suivie d’une stratégie de sécurité. Un récent rapport de Netwrix interrogeant 600 professionnels de l’IT révèle que 57% des personnes qui ont répondu ont réalisé des processus de changement non documentés sur leur système IT. D’autres chiffres soulignent que 65% ont réalisé des modifications qui ont conduit à une interruption de systèmes, alors que, chiffre étonnant, 39% ont fait des modifications qui ont conduit à des failles de sécurité. Le rapport révèle par ailleurs que 40% des organisations ne possèdent pas de processus formalisés de contrôle pour les modifications d’une politique de management des systèmes informatiques.

Que se passe-t-il alors ? La plupart des directeurs informatiques se réfèrent encore à des processus manuels chronophages, qui impliquent des consultations de pages et de pages d’audit de logs provenant de serveurs ou d’autres parties d’un équipement réseau. Dans leur forme brute, ces pages de logs créent un amoncellement de données techniques illisibles et non nécessaires, qui n’ont aucun sens sans processus de filtrage ou de traduction. De manière surprenante, cette approche effectuée a posteriori, et non sécurisée est encore répandue, même dans les grandes entreprises.

Trop petit, trop tard

Avec beaucoup d’audits effectués une fois par an, ou bien seulement lorsque un évènement fâcheux s’est produit, comme une perte de données, très peu d’équipes informatiques savent réellement ce qui se passe à tout moment sur leur infrastructure IT. Et, dans le cadre d’un environnement informatique physique et virtuel de plus en plus complexe, il existe un certain nombre d’éléments dont il faut avoir une traçabilité complète.

Par exemple, Active Directory est au cœur de 98% de la plupart des réseaux modernes ; la majorité des entreprises ne comprend pas pourquoi il existe un problème avec leur Active Directory. Il se passe la même chose pour les politiques corporate quand on mène par exemple des audits sur les politiques de changement de mot de passe. Et, avec une utilisation croissante de l’e-mail, il est vital de surveiller de manière continue les changements, soit fait par erreur, soit les changements malicieux, effectués dans Microsoft Exchange, notamment en sachant qui a accès à quelle boîte mail, quand, et pour faire quoi. La réduction de la fuite de données dépend de cette information.

Le besoin de savoir

Quand il concerne des serveurs critiques, le besoin de savoir paraît évident. Cependant, très peu d’organisations ont élaboré une stratégie significative pour auditer de manière basique l’accès aux fichiers, afin de répondre à des questions aussi simples que de savoir qui a eu accès à un dossier ; quand y a-t-on eu accès ; la tentative d’accès a-t-elle été couronnée de succès ou rejetée ? Des serveurs qui gèrent des données personnelles et commerciales sensibles créent une menace particulière de sécurité, et demandent une attention particulière pour savoir quels changements ont été effectués et qui les a effectués.

La tendance à la virtualisation crée de nouveaux défis. Au moment où il est plus facile que jamais de mettre en place de nouveaux serveurs et de faire démarrer de nouvelles applications, gérer ces serveurs et ces applications peut s’avérer très complexe, et comprendre ce qui se passe sur les serveurs est important, voire plus important, que de gérer l’infrastructure physique.

Finalement, savoir qui se connecte au réseau, d’où, pour faire quoi et sur quelle durée, devrait être une pratique de sécurité de base. Mais si les entreprises comptent sur des outils natifs pour effectuer cette tâche, Ils n’auront pas accès à cette information sous une forme exploitable.

Les approches de l’audit

Les audits de changements ne sont pas des procédures compliquées. Comprendre les approches les plus répandues peut aider à déterminer ce qui convient le mieux à l’organisation. Il n’existe pas de solution unique, et la réponse va dépendre des exigences, du temps et de l’argent que vous êtes prêts à y investir.
Il est possible de créer des conditions de conformité nécessaires en utilisant des audits de logs natifs et des processus manuels, mais trier les données pertinentes d’un « bruit » ambiant excessif est chronophage, et en soi peu sécurisé, car les logs natifs peuvent être édités, détruits et modifiés sans trace. Il manque aussi une solution de stockage ou d’archivage qui répond à des exigences de conformité.
Le SIEM –Security Information and Event Management- est une seconde approche pour changer les procédures d’audit. Mais les coûts d’investissement et de maintenance demandés par le SIEM peuvent être justifiés, seulement si l’on souhaite intégrer des fonctions comme la remédiation automatique et les préventions d’intrusion. C’est une option qui peut s’avérer coûteuse. Même dans le cas où un SIEM est implanté, il ne fournit pas de solution d’audit exploitable, parce qu’il est le plus souvent relié aux données dans les journaux de logs natifs. C’est un cas typique de « garbage in, garbage out ».

Créer son propre système d’audit de changement peut être une troisième option. Même s’il peut s’avérer utile de mettre en place une solution spécifique, cela prend beaucoup de temps, et les ressources techniques demandent souvent une utilisation d’API (Application Programming Interfaces) non autorisées pour collecter des données d’audit, qui véhiculent des risques intrinsèques.

La quatrième voie

Enfin, une approche alternative peut être d’utiliser un logiciel spécialisé d’audit de changement. Ces solutions peuvent donner une image détaillée, fiable, et cohérente de ce qui se passe sur l’infrastructure informatique dans son intégralité pour à peu près le tiers du coût d’une solution SIEM. Plus important, les logiciels d’audit de changement utilisent de multiples flux de données provenant de sources multiples, les filtrent, les traduisent, éditent et compressent le résultat pour un accès rapide, compréhensible et archivable.

Pour obtenir une image précise de ce qui se passe sur le réseau, il faut être capable d’obtenir un instantané de la situation avant et après qu’un changement ait été effectué. Cette approche coopérative plus ciblée pour auditer les changements peut alors fournir des alertes « temps réel », et des rapports automatiques pour améliorer le contrôle, la détection et l’analyse
Il n’y a pas de solution simple pour savoir ce qui se passe sur les infrastructures informatiques. Mais s’il est impossible de savoir qui a accès au réseau , d’où, et quand, sans passer des heures à connaître les réponses, il est temps d’étudier sérieusement une solution d’audit informatique.


Voir les articles précédents

    

Voir les articles suivants