Mettez-vous en conformité : éliminez les risques majeurs !

Nos cadres demandent des directives aux auditeurs et ceux-ci se tournent vers les sections sécurité de COBIT (Control Objectives for Information and related Technology). Si COBIT ne vous est pas encore familier, consultez-le en ligne à isaca.org. Le but de COBIT est d’être un standard pour la sécurité et le contrôle des technologies de l’information. Il fournit aux entreprises le cadre qui les mettra en conformité avec la législation et la réglementation actuelles. Les auditeurs font leurs recommandations sur le plan commercial et technique en matière de conformité et c’est à nous, administrateurs, de les appliquer en tenant compte des stratégies de contrôle et de sécurité de l’entreprise. Dans le monde réglementé qui est le nôtre, l’opinion de l’auditeur est devenu parole d’évangile.

En général, dans un site iSeries, les auditeurs techniques recherchent des configurations iSeries spécifiques permettant d’instaurer une séparation stricte des tâches et des responsabilités, et d’assurer la confidentialité des données sensibles.
La séparation des tâches et des responsabilités dans le domaine technique repose sur la règle suivante : l’utilisateur d’un système ne peut pas effectuer une tâche qui n’entre pas dans le cadre de ses responsabilités professionnelles. Ainsi, l’utilisateur qui crée un bon de commande ne peut pas aussi l’approuver. Ou celui qui soumet une feuille de frais ou une fiche de débours ne peut pas approuver ce document et encore moins rédiger le chèque de remboursement. Dans le même esprit, le responsable de la sécurité système ne peut pas aussi être chargé des achats, pas plus qu’il ne saurait être un programmeur d’application de gestion.

Pour maintenir une stricte séparation des responsabilités, nos stratégies de contrôle d’accès doivent être très précises sur certains points : de quelles interfaces dispose chaque utilisateur (Telnet, FTP, ODBC, par exemple), pour quelles fonctions (transférer des données, se connecter, lire, mettre à jour, supprimer des données), pour quelles tâches (paie, comptabilité générale, comptabilité clients, prix). Ce n’est pas parce qu’un utilisateur est autorisé à mettre à jour le fichier de paie au moyen de son interface Telnet, qu’il a aussi le droit de transférer le fichier de paie sur son PC. Il faut instaurer des contrôles permettant de détecter et de prévenir toute tentative de transgression.

Dans les pays anglo-saxons, de nombreuses lois et réglementations, comme le HIPAA (Health Insurance Portability and Accountability Act) et le nouveau Payment Card Industry Data Security Stanrdard (PCI Standard), exigent la confidentialité des données. Les données du genre historique médical, numéros de sécurité sociale, numéros de cartes de crédit, numéros et soldes de comptes bancaires, doivent être protégées. On a assisté récemment à beaucoup de violations de la confidentialité des données, avec l’exposition d’informations personnelles et bancaires sur Internet. Là encore, nous devons être capables de détecter et de prévenir les tentatives malignes.

Je suis rédacteur et auteur technique pour iSeries NEWS, mais j’exerce aussi un autre travail. En tant que représentant de services techniques pour un fournisseur de logiciels de sécurité et de services iSeries, je conduis souvent des audits de sécurité iSeries pour nos clients. Mon rôle est de les aider à configurer correctement leurs machines iSeries dans un double but : sécuriser davantage le système et démontrer la conformité avec les stratégies et réglementations existantes.
Les principaux risques de sécurité que je présente ici sont le fruit de ces audits et de nombreux échanges de vues avec les clients. Très concrets, ces scénarios mettent le doigt sur les problèmes de sécurité qui concernent la plupart d’entre nous. Cet article n’expose pas tous les problèmes de sécurité rencontrés au fil de mon activité. Il décrit plutôt les failles les plus répandues constatées dans les installations iSeries de toutes tailles.