Principes sur la traçabilité sur SWIFTNet

Qu’est ce que la traçabilité ? Et quel rôle joue-t-elle dans la sécurité ? Ces deux questions seront examinées dans cet article.

En préambule, il est important de mentionner que le mot traçabilité comporte de nombreuses définitions et est compris de différentes façons selon qu’on parle de production, d’achat, de sécurité, etc. Nous allons le définir du point de vue de la sécurité.

Vu sous le prisme de la sécurité, la traçabilité a pour objectif premier d’identifier et conserver les preuves d’accès ou de tentatives d’accès aux systèmes et ressources informatiques. Les traces ou preuves doivent être exploitables et permettre le cas échéant de retrouver qui ou quoi a accédé ou essayé d’accéder à quel système. Le terme piste d’audit est souvent confondu avec la traçabilité. Si les deux ont des points communs, ils ne désignent pas la même chose. La piste d’audit permet la reconstitution et la vérification des séquences d’évènements ayant mené à un résultat déterminé. La piste d’audit combine un ensemble de preuves pour raconter l’histoire; ce qu’il s’est passé. Elle englobe donc davantage de choses que la traçabilité. Pour résumer simplement : sans traçabilité, il ne peut y avoir de piste d’audit. Prenons le cas d’un virement effectué de façon frauduleuse pour mieux l’illustrer. La traçabilité se limite à la conservation des preuves d’accès et de modification du système alors que la piste d’audit établit le lien entre toutes les preuves et permet ainsi de « raconter » l’histoire. On peut refaire l’histoire à travers les traces, mais cela peut parfois nécessiter un temps considérable. La piste d’audit, elle nous raconte directement l’histoire. Il faut donc des traitements informatiques plus élaborer pour réaliser une piste d’audit.

Les traces sont souvent enregistrées dans ce qu’on appelle les logs ou historiques d’évènements. Il s’agit d’un journal (un fichier texte) où on peut voir tous les évènements avec ou sans intervention humaine qui ont lieu pendant les traitements informatiques. Ils sont généralement datés et classés par ordre chronologique. Le traçage n’est pas automatique. Les évènements n’apparaissent dans les logs que s’ils ont été programmés ainsi. Il est donc nécessaire de bien identifier les évènements qui doivent être conservés et de s’assurer, pendant les phases de tests, que l’implémentation a été réalisée correctement.

Les logs posent essentiellement deux problèmes pour la recherche ou la remontée des preuves d’accès non autorisées :

• Elles ne sont pas très faciles à lire. C’est un fichier texte avec une taille pouvant aller jusqu’à des centaines de Megaoctets d’informations. La plupart de ces informations présente peu d’intérêt. Par conséquent, retrouver l’information recherchée peut demander beaucoup de temps.
• S’il y a eu un accès non autorisé, il faudrait normalement que l’information remonte automatiquement à qui de droit. La log n’est pas suffisamment intelligente pour envoyer une alerte. Il faudrait donc prévoir des programmes supplémentaires qui scannent les logs pour détecter ce genre d’information et la transmettre à qui de droit.

Par palier à ces inconvénients, de nombreuses applications vendues sur le marché offrent la traçabilité comme une fonctionnalité à part entière.

La traçabilité sur le réseau SwiftNet : Toutes les actions des utilisateurs sont tracées et conservées sur les applications SWIFT. Il est donc possible de retrouver quand un utilisateur s’est connecté, ce qu’il a fait comme actions ainsi que les résultats associés et quand il s’est déconnecté. SWIFT est big brother ? La réponse est : Oui sur son réseau ; Mais Non une fois qu’on considère les choses hors du réseau de SWIFT. Tout ce qui se passe sur le réseau doit être tracé. C’est vital pour SWIFT et pour ses clients puisque les montants en jeu sont mirobolants.

Nous terminons ainsi les articles sur les services de sécurité. Tout au long de ces articles, nous avons souvent parlé du système PKI. Il fera l’objet du prochain article.