Déclencheurs d’un audit informatique

Les audits ont parfois un aspect très rigoureux et peuvent être perçus comme menaçants ou inamicaux par les participants inexpérimentés. Cette perception est souvent renforcée par des scènes de télévision où des légions d’avocats « envahissent » une entreprise pour la mettre sens dessus dessous. Mais est-ce toujours ainsi ? En effet, ce type d’audit existe, généralement en lien avec des violations légales ou des accusations similaires, où l’atmosphère peut être effectivement plus « rude ». Des termes tels que « Compliance Audit » ou « Litigation Audit » sont souvent utilisés dans ce contexte. Cependant, même dans ce cas, la présomption d’innocence s’applique dans un premier temps, et la procédure dans nos régions n’a pas nécessairement de points communs avec celle suggérée par Hollywood.

Dans de nombreux cas, les raisons d’un audit sont beaucoup plus amicales, mais néanmoins tout aussi structurées et liées à une approche professionnelle. Une entreprise souhaite se développer et s’interroge sur l’adéquation de son infrastructure informatique actuelle à cette croissance. Des questions exemplaires peuvent être : Les capacités du centre de données sont-elles suffisantes, l’infrastructure est-elle suffisamment redondante, l’équipe peut-elle couvrir les horaires de service étendus ? Un autre exemple concerne les certifications spéciales, où l’entreprise s’est engagée à suivre certains cadres de processus (par exemple, ISO 27001 ou ISO 9001), et dont le respect doit être vérifié par échantillonnage lors de la recertification. En particulier dans le secteur financier, dans le cadre des directives de Bâle, la gestion des risques nécessaire[1] est en grande partie liée à des processus informatiques correspondants, qui doivent être régulièrement vérifiés. Parfois, il s’agit moins de la manière dont les opérations informatiques sont menées que des structures de coûts sous-jacentes. Un « examen » régulier des anciens contrats et une comparaison avec les prix actuels du marché peuvent révéler des potentiels significatifs d’optimisation des coûts.

Approche

Quelle que soit la raison de l’audit (ordonné), dans presque tous les cas, l’équipe d’audit cherche à établir une bonne relation avec les personnes concernées, car une collaboration coopérative permet d’accomplir les tâches beaucoup plus rapidement et efficacement. Chez digatus, nous appliquons à cette fin une approche transparente basée sur les normes actuelles de l’industrie[2], qui a fait ses preuves dans les projets précédents.

L’élément central est une communication claire du projet au début de l’audit, afin de transmettre clairement les attentes du client ainsi que les tâches de coopération du domaine à auditer à toutes les personnes impliquées. En particulier dans notre premier cas, l’« Audit de Conformité », visant à identifier les violations présumées ou les comportements inappropriés d’individus ou de départements spécifiques, une coopération élevée des personnes concernées est nécessaire afin que les preuves respectives soient identifiées et trouvées dans une collaboration constructive. La situation devient plus délicate lorsque la coopération fait défaut, que les données nécessaires ont été supprimées ou même que l’on a tenté de les détruire par des dommages physiques. Dans une telle situation, des spécialistes sont déployés, capables d’extraire minutieusement des données brutes individuelles de n’importe quel support de données, pièce par pièce, et de reconstituer le « grand ensemble » à partir de ces fragments. L’observation de ces collègues au travail donne souvent plus l’impression d’un laboratoire de recherche que d’une entreprise informatique, et toutes sortes d’outils et d’instruments spéciaux sont utilisés. Les lecteurs intéressés sont invités à consulter le « Guide de l’informatique légale »[3] de l’Office fédéral de la sécurité des technologies de l’information (BSI), qui offre un bon aperçu et décrit les scénarios et modèles d’approche possibles.

La situation est différente lorsqu’il s’agit de la croissance de l’entreprise mentionnée ou de la vérification du respect des modèles de processus. Dans ce cas, les possibilités sont en principe illimitées, et la nature et l’étendue de l’audit doivent être convenues avec le client et ses attentes. Dans le cas le plus simple, les capacités informatiques existantes sont examinées, une planification des augmentations attendues est élaborée conjointement avec l’équipe informatique, et celle-ci est comparée aux possibilités constatées. Dans une variante plus approfondie, l’état de maintenance d’un paysage informatique peut également être vérifié en examinant les versions des composants utilisés en termes de logiciels et de micrologiciels, et en les comparant aux recommandations des fabricants. Avec une approche élargie, les contrats de support et de maintenance existants peuvent également être examinés, ainsi que la mesure dans laquelle les produits utilisés sont encore supportés par le fabricant et, par exemple, si l’approvisionnement en pièces de rechange est assuré en cas de défaillance. Si l’on souhaite aller encore plus loin, les systèmes et processus concernés peuvent être soumis à une charge réelle par des tests « Real-World » et leur comportement respectif peut être évalué. Dans le domaine de la sécurité (pare-feu, services Web publics, etc.), on utilise ce qu’on appelle des « tests de pénétration » (également appelés « Pen-Test »). Ceux-ci tentent d’identifier les failles de sécurité ou les comportements indésirables par surcharge ou épuisement sur les systèmes concernés à l’aide de logiciels spéciaux. Un exemple dans le domaine de la sécurité est le projet « OWASP »[4] pour la vérification des applications, qui dispose d’une collection d’approches et d’outils de meilleures pratiques. Il n’est pas rare que de nombreux outils développés par l’auditeur lui-même soient utilisés dans cette approche, représentant son expertise spécifique.

La situation est légèrement différente dans le domaine des tests de charge, par exemple pour les boutiques en ligne ou les systèmes ERP, où l’objectif est d’explorer les limites de charge respectives en générant artificiellement une utilisation (commandes, visiteurs simultanés, processus de production, etc.). En particulier dans le domaine des systèmes de commerce et des boutiques en ligne, par exemple, un temps de chargement de plus de trois secondes sur une page de commande peut entraîner un pourcentage à deux chiffres significatif de clients qui abandonnent et ne finalisent pas leur achat, ayant ainsi un impact direct sur le succès commercial de l’entreprise[5]. Enfin, dans le cadre de tels projets d’audit, des scénarios de basculement ou la capacité de réaction des processus de service, etc. peuvent également être testés, l’équipe d’audit procédant, en étroite coordination avec le client, à des arrêts ciblés mais non annoncés ou à la déconnexion de composants individuels, du simple commutateur de périphérie au commutateur central, en passant par le système ERP ou le contrôleur de domaine. Dans ce cas, les solutions informatiques respectives peuvent maintenant prouver leur redondance, ou dans le cas des équipes de service, démontrer leur capacité à identifier rapidement et de manière ciblée la source correcte de l’erreur, ainsi qu’à la résoudre.

L’examen des contrats avec les prestataires de services est beaucoup plus théorique, l’objectif principal étant de comparer l’étendue actuelle des services prévus dans les contrats avec ce qui est effectivement fourni, ainsi que d’identifier les économies potentielles en comparant avec les prix actuels du marché.

Résultats

La présentation des approches le laisse entrevoir – les résultats d’un audit informatique peuvent être aussi variés que les modèles de procédure. Afin de se conformer aux attentes du donneur d’ordre, il est crucial de clarifier les exigences dès le début, pour s’assurer qu’un modèle permettant d’obtenir les données nécessaires pour l’étendue souhaitée des résultats soit choisi dans l’approche. Habituellement, les connaissances générées dans le cadre des audits sont présentées lors d’une présentation finale, et un document de résultats est élaboré pour le client, comprenant les exigences, les composants, systèmes ou processus traités ainsi que leurs résultats. Chez digatus, nous croyons que simplement pointer du doigt les problèmes ou les besoins d’action n’est pas suffisant, et malheureusement, trop souvent de bons résultats d’audit disparaissent dans des tiroirs sans amélioration. C’est pourquoi nous donnons toujours dans ce contexte des recommandations d’action concrètes pour résoudre les problèmes identifiés – sur demande, avec le soutien de notre équipe.

[1] Cf. BCBS 239, https://en.wikipedia.org/wiki/BCBS_239

[2] Cf. Springer : Révision informatique, Audit informatique et Conformité informatique, ISBN 978-3-658-23764-6

[3] BSI : Guide de l’informatique légale, https://www.bsi.bund.de/DE/Themen/Cyber-Sicherheit/Dienstleistungen/IT-Forensik/forensik_node.html

[4] The Open Web Application Security Project (OWASP), https://www.owasp.org/index.php/Main_Page

[5] Dyn : Rapport 2015 : Attentes mondiales des consommateurs en matière d’achats en ligne, http://pages.dyn.com/rs/dyn/images/Dyn%202015%20Report-Global%20Consumer%20Online%20Shopping%20Expectations.pdf[/artikel_text]