Contrôle Prudentiel et Systèmes d'Information

Dans le milieu IT bancaire, on entend souvent parler d'obligations légales pour l'organisation de PCA/PRA et autres, sans trop savoir s'il s'agit réellement d'obligations et de comment elles ont été imposées. Alors que la redondance d'équipements et l'attribution de logins individuels semblent découler du simple bon sens, il m'a semblé utile d'approfondir la base légale de leur mise en pratique pour constater le périmètre et la profondeur de ces éventuelles obligations. Cet article s'adresse donc à n'importe quel intervenant informatique du milieu bancaire, de l'administrateur système au RSSI en passant par le DSI.

Cadre historique et légal
Depuis 1974, le Comité de Bâle définit un certain nombre de standards et pratiques pour les banques à dimension internationale situées dans les pays (une centaine environ) qui ont choisi d'adopter cette règlementation. Démarrées en 1988 et publiées en juin 2004, les normes Bâle II introduisent la notion de risque informatique dans le cadre plus général des risques opérationnels (§736).
Ces normes devant être retranscrites dans les cadres juridiques nationaux respectifs, cela passe pour le cas des USA par la loi SOX, et pour le cas de l'Union Européenne par la directive CRD, elle-même devant être retranscrite en lois nationales comme toute autre directive émise par l'UE. Il est intéressant de noter que la législation américaine devançait le sujet car la loi SOX remonte à 2002, quand la loi CRD a été adoptée deux ans après Bâle II soit en juin 2006, et finalement transcrite en loi française en février 2007. Respectivement pour l'UE et la France, il s'agit de la référence exacte 2006-48 et d'un ensemble de lois, arrêtés, ordonnances et décrets.
A ces textes provenant de Bâle II, s'ajoutent ceux purement nationaux et déjà anciens en particulier le CRBF 97.02 datant de 1997 et souvent rectifié depuis.
En France et depuis 2010, l'Autorité de Contrôle Prudentiel et de Résolution (ACPR) adossée à la Banque de France est chargée de la supervision des banques et assurances, et par conséquent du sujet qui nous intéresse : les règles prudentielles concernant les systèmes d'information. Une dizaine de personnes seraient affectées à cette mission précise de supervision et contrôle par l'ACPR.

Bâle II
Le texte issu de Bâle II ne s'étend pas beaucoup sur les systèmes d'information en tant que tels. En fait, il les mentionne parmi les risques opérationnels suivants :

• Fraude Externe/Sécurité des Systèmes (Dommages dus au piratage informatique/Vol d'informations avec perte financière)
• Interruptions d'activité et dysfonctionnements des systèmes/Systèmes (Matériel, Logiciel, Télécommunications)

Selon Bâle II, le risque opérationnel équivaut à une situation pouvant engendrer des pertes financières (§644). Lorsque des pertes surviennent, elles doivent être consignées (§670) en faisant apparaître leur origine (§671) et cela reste vrai pour des pertes provenant d'un défaut informatique.
Cette règlementation indique par ailleurs que les contrôles doivent être réalisés respectivement par les autorités nationales de contrôles, ce qui va donc légitimer les interventions de l'ACPR pour cette même règlementation ainsi que pour CRBF 97-02.

CRBF 97-02
Le règlement CRBF 97-02 régit le contrôle interne des établissements de crédit et des entreprises d'investissement. Ainsi, toutes les banques sont concernées indépendamment de leur taille ou de leur exposition internationale.
De même que dans Bâle II, nous y retrouvons les notions de risque opérationnel (art. 4.j) et d'interruption d'activité sous une dénomination inverse de plan de continuité d'activité (art. 4.n). Transcrites en droit français par des arrêtés datant aussi de février et juillet 2007, nous constatons que ces notions ont un sens identique que dans la règlementation Bâle II.
Précisément, les systèmes d'information (art. 5.e) doivent faire l'objet de contrôles prouvant qu'ils sont conformes aux règlements, normes et pratiques professionnelles (art. 5.a). Au même titre que toutes les autres, les non-conformités du système d'information doivent être communiquées au responsable en charge de la filière "risques", lui-même étant déclaré auprès de la Commission bancaire (art. 11.8). A noter que cette personne est directement rattachée à l'exécutif de l'entreprise et ne doit pas exercer de fonction commerciale, financière ou comptable.
Le niveau de sécurité du système d'information est laissé à la libre appréciation du propriétaire (art. 14), doit être régulièrement testé et corrigé (art. 14.a), et il doit assurer la confidentialité et l'intégrité des données (art. 14.c). La disponibilité des données, et c'est une petite lacune que l'on peut reprocher à ce document, n'est pas mentionnée en tant que telle mais indirectement au travers de la disponibilité des ressources humaines, techniques et immobilières (art. 14-1). Outre un dernier rappel sur le plan de continuité d'activité (art. 14-1.c), il reste l'obligation de documenter les analyses et les traitements.
Enfin, la mise en oeuvre de toutes ces dispositions est suggérée par l'application des normes et bonnes pratiques de la sécurité des systèmes d'informations, en particulier ISO 27002, ISO 38500, et la littérature émise par les organismes liés à la régulation bancaire (livres blancs, rapports,..)

ISO 27002
Le standard ISO 27002 dont la dernière version est ISO27002:2013, est un ensemble de bonnes pratiques et recommendations pour la sécurité des systèmes d'information. On y trouve 114 points de contrôle décrivant le classique trio confidentialité, intégrité, et disponibilité de l'information. Etant trop long et sans intérêt à résumer, consulter directement ce standard ou bien ce document qui en fait une bonne présentation et synthétise ses forces et faiblesses de façon honnête.

ISO 38500
Le standard ISO 38500 définit la gouvernance des technologies de l'information, et un bon aperçu est donné par wikipedia. Par ce standard, le système d'information n'est plus un domaine isolé du reste de l'entreprise mais rejoint la stratégie générale de l'entreprise. Aussi, il n'est plus considéré absolument comme un centre de coût mais comme créateur de valeur. Dans les grandes lignes ce standard suggère la connaissance du parc matériel et logiciel ainsi que les évolutions nécessaires, l'appréciation de sa valeur et de sa rentabilité, et enfin des risques qui y sont associés. Pour le détail, mieux vaut se reporter au document source.

Sources complémentaires
Le Rapport Lagarde publié en février 2008 après la perte historique de Société Générale dit ceci : "Les systèmes d’information doivent être correctement sécurisés, afin d’éviter les intrusions. En particulier, les modes d’accès doivent faire l’objet d’une procédure approuvée par les dirigeants." C'est expéditif sans rien apporter de nouveau au sujet.

Le Livre blanc sur la sécurité des systèmes d'information dans les établissements de crédit publié par la Commission Bancaire en 1996 constitue la source la plus ancienne qui détaille les risques et donne des indications sur comment atteindre un objectif de sécurité convenable. Composé de 4 grands chapitres (risques du SI, outils de mesure du risque, parades, recommandations), il donne beaucoup d'exemples et de l'information suffisamment détaillée pour être utile à n'importe quel niveau de la chaîne opérationnelle. A noter qu'au classique trio confidentialité/intégrité/disponibilité s'ajoute un quatrième vecteur : la non-répudiation. Cette caractéristique impose de ne pas pouvoir nier l'émission ou la réception d'une donnée, et peut-être revendiquée pour la demande d'une preuve. Ce livre blanc étant d'une certaine consistance, il est recommandé de le parcourir en particulier pour ses fiches conseils même si certains points paraissent obsolètes et pourraient être formulés différemment aujourd'hui (par exemple : doit-on encore se méfier de Linux au titre qu'il s'agit d'un "système ouvert" ?).