Yphise accompagne les décideurs et managers dans leurs réflexions, décisions et actions

Transcription

1 Démontrer la conformité (compliance) d une production informatique WITO - Novembre 2008 Xavier Flez yphise@yphise.com GM Gouvernance PR Projets IS Systèmes d Information SO Service Management 1

2 La sensibilité au risque La sensibilité au risque va monter. On peut perdre beaucoup, voire tout, à cause d un événement ; fraude, législation ou engagement non respecté. Un grand enseignement de la crise en cours est que l événement peut être lointain, et au départ relativement mineur. Ex. Les défauts de remboursement par des ménages US de leur prêt immobilier, ce n est pas le tremblement de terre qui anéantira San Francisco ou Tokyo. 2

3 Le management du risque Il y a deux dimensions dans le management du risque. 1) la réduction du risque (response) et 2) le contrôle que la réponse a été appliquée et est pertinente. La réduction du risque consiste à mettre dans le processus de l entreprise les dispositifs pour supprimer le risque ou le réduire à un niveau jugé acceptable (risk appetite). «Normalement», il n y a donc plus de risque dans le processus ou le risque résiduel est acceptable. Mais, on va néanmoins contrôler que les dispositifs de réponse sont appliqués et pertinents. Ex. Risque de fraude ou de mauvaise décision. Réponse. On va définir des niveaux d engagement ou d autorité sur des crédits, achats, ordres de bourse, etc. Contrôle. On va s assurer du respect effectif de ces règles et de leur pertinence. 3

4 Le contrôle interne Ce contrôle est appelé le contrôle interne (internal control). Ce contrôle interne est un enjeu grandissant dans les entreprises. C est aussi un sujet récent et compliqué. Il n a pas encore trouvé sa maturité : le comment faire simple et efficace reste à inventer, le risque procédurier est élevé. Quelques dates SOX oblige les entreprises cotées à évaluer leur contrôle interne France Loi de Sécurité Financière, plus légère que SOX, adresse le contrôle interne Publication du référentiel COSO 2 sur la gestion du risque. 4

5 Contrôle interne versus vérification et validation : général Ce contrôle regarde ou se met sur le fonctionnement opérationnel du processus considéré. Il contrôle la conformité (compliance) de sa réalisation opérationnelle. La vérification et la validation, c est-à-dire le test, d un processus avant son déploiement opérationnel est aussi une forme de contrôle. Ce n est pas le contrôle interne. Voyons comment cela se traduit pour une production informatique. 5

6 Contrôle interne versus vérification et validation : production informatique La production informatique a été conçue par le Service Design, puis vérifiée et validée par le Service Transition. La production est donc «normalement» conforme à ce qu elle doit être. Elle a été contrôlée pour s assurer qu elle est à même - de tenir les SLA, - reprendre sur sinistre, - empêcher la fraude. Le contrôle interne regarde si la production en opérationnel est effectivement conforme. Différents outils peuvent déjà s inscrire dans cette perspective : monitoring de production, base d incidents. On va voir qu il y en a d autres. Progressivement, les entreprises vont demander à leur informatique un véritable système de contrôle interne. 6

7 Les risques à contrôler : général Le contrôle interne s apprécie face à des risques pour l entreprise sur ses processus (COSO 2). Ces risques ont été analysés. A été fait ce qu il fallait en «Design et Transition» de chaque processus pour répondre à ces risques. Le contrôle interne assure que cette réponse aux risques est effective et efficace. Il faut donc commencer par analyser les risques relatifs aux systèmes d information dans leur fonctionnement en production. 7

8 Les risques à contrôler : production informatique (1/2) Différents risques sont relatifs aux systèmes d information dans leur fonctionnement en production. L incapacité à donner aux utilisateurs externes (clients, prospects, partenaires) les performances attendues. L incapacité à tenir les engagements de service utiles sur les opérations métier («de bout en bout»). La fraude par utilisation d ID/Password et de droits d accès. La fraude par utilisation de faiblesses techniques. L incapacité à reprendre sur sinistre (c est-à-dire à exécuter le plan de secours). L utilisation de logiciels sans licence. 8

9 Les risques à contrôler : production informatique (2/2) Le Service Design et le Service Transition ont analysé ces risques. Ils ont mis en place les moyens pour les supprimer ou les réduire à un niveau acceptable. Service Design Le SLM, Capacity et Availability Mngt ont analysé les besoins de SLA et mené une conception en conséquence. L Information Security Mngt a analysé et réduit les risques liés aux droits d accès. L IT Service Continuity Mngt a mis en place le plan de secours. Service Transition Le Service Asset and Configuration Mngt a vérifié l utilisation légale des licences et les configurations. Le Service Validation and Testing a vérifié et validé les changements. 9

10 La mise en place d un système de contrôle interne Il faut maintenant mettre en place le contrôle interne. Ce n est pas un sujet traité par ITIL v3. Selon la circonstance, le contrôle interne peut être ponctuel ou continu, par des procédures manuelles ou outillé. L enjeu du contrôle interne est d éviter «les trous», de générer une charge de travail nouvelle et procédurière. On a toujours intérêt à privilégier le continu. Il nécessite de fait un outillage. Que pouvons nous donc faire dans le cas d une production informatique? 10

11 Des familles de progiciels qui arrivent à maturité L investissement en progiciels est aujourd hui centré sur les solutions de service management. CMS - Service Catalog - gestion des processus d incidents, problèmes, changements. Ces solutions ne traitent pas notre besoin de contrôle interne. Il faut chercher ailleurs. Différentes familles de solutions arrivent aujourd hui à maturité, sont refondues où voient leur valeur s élargir pour ce besoin. EUEM - End-User Experience Monitoring BAM - Business Activity Monitoring UBCA - User Behavior and Compliance Audit SCCA - Server Compliance and Configuration Audit IRMC - Integrated Risk Management and Control SAM - Software Asset Management C est très important de savoir les positionner dans l enjeu de contrôle interne. Sinon, les «dérives procédurières» venant de risk managers ou contrôleurs sont inévitables. Nous allons les reprendre face aux risques. 11

12 1) Les performances attendues par les utilisateurs externes Le risque est l incapacité à donner aux utilisateurs externes (clients, prospects, partenaires) les performances attendues. Le contrôle interne va naturellement porter sur le maintien de la disponibilité et de la performance effectives des applications à l utilisateur. Un contrôle continu et outillé se fait très bien : EUEM - End-User Experience Monitoring. Ce «business case» est mature. Il est au portefeuille des opportunités de projet Yphise depuis Mais les solutions ont évolué dans leur principe pour une mesure réelle de «l expérience utilisateur» : de l installation d agents qui jouent des scénarios prédéfinis, au regard des flux réseau pour reconstituer le trafic d un utilisateur. Les solutions permettent en outre un certain contrôle de l intégrité des applications : la disponibilité est prononcée au regard de patterns de données. 12

13 2) Les engagements de service sur les opérations métier Le risque est l incapacité à tenir les engagements de service utiles sur les opérations métier. Le point clé est une mesure «de bout en bout» d un flux métier qui peut passer par différentes applications, systèmes d information ou activités non informatisée (ex transport). On n est pas sur le temps de réponse d une application, mais sur la durée d exécution d une opération métier en minutes, heures, jours, parfois mois. Un contrôle continu et outillé se fait très bien : BAM - Business Activity Monitoring. Ce «business case» est mature. Il est au portefeuille des opportunités de projet Yphise depuis Il couvre une gamme diversifiée de solutions selon le contexte. Jusqu à présent, l achat d une solution de BAM n était pas pour du contrôle interne mais pour piloter l opérationnel d un métier. Le contrôle interne étend le périmètre d utilisation et donc accroit le ROI. 13

14 3) La fraude par utilisation d ID/Password Les ID/Password, profils et droits d accès ont été bien conçus (Service Design). Leur gestion opérationnelle est assurée (Service Operation). Le risque est de fraude par utilisation «bizarre» ou anormale de ces droits. Un contrôle continu et outillé est possible : UBCA - User Behavior Compliance Monitoring. Sans outillage, ce contrôle est d ailleurs illusoire. Ce «business case» est innovant. Il est centré sur le contrôle interne. Il est au portefeuille des opportunités de projet Yphise pour la 1ere fois en Les solutions d UBCA collectent des logs, pistes d audit ou autres données hétérogènes, gèrent ces ensembles très volumineux, cherchent les patterns anormaux, les mettent en évidence pour appréciation, alertent sur détection d un pattern anormal. 14

15 4) La fraude par utilisation de faiblesses techniques La configuration des serveurs - logiciel installé, niveaux de patch, paramétrage système, paramétrage sous-systèmes sensibles (ex queueing) - a été bien conçue (Service Design) et déployée (Service Transition). Le risque est de fraude par modification de cette configuration. Le risque est aussi le dysfonctionnement du système d information voire sa perte d intégrité. Le contrôle interne va porter sur les écarts entre une situation actuelle et une référence ou les changements entre deux mesures. Un contrôle continu et outillé est possible : SCCA - Server Configuration Compliance Audit. Sans outillage, ce contrôle est d ailleurs illusoire. L origine est la sécurité : supprimer les failles de sécurité. L évolution est le couplage avec les solutions de Change Management. Attention : une solution de CMS ne convient pas. Ce «business case» date du début des années 2000 pour une orientation sécurité. Le centrage sur la conformité est récent : il a été sélectionné dans le portefeuille des opportunités de projet Yphise pour la 1ere fois en

16 5) L incapacité à reprendre sur sinistre On a un plan de secours (Service Design) vérifié et validé dans la mesure du possible (Service Transition). Le risque est d incapacité à repartir parce que ce plan de secours n est plus adapté compte tenu de tous les projets applicatifs ou techniques menés depuis. Le contrôle doit porter sur la réalité de la mise à jour du plan de secours au fur et à mesure des projets. Une solution classique de contrôle interne : IRMC - Integrated Risk Management and Control. Contrôle interne de type «Ponctuel selon des procédures manuelles». Une campagne de contrôle demande aux interlocuteurs concernés de confirmer ou prouver la mise à jour sur tels projets. Ce «business case» est nouveau. Il est au portefeuille des opportunités de projet Yphise pour la 1ere fois en Nous pensons que cela a un intérêt pour une DSI d investir sur une solution d IRMC : le contrôle du plan de secours est l application la plus immédiate et évidente. 16

17 6) L utilisation de logiciels sans licence Le risque est l utilisation sans licence de logiciels dans les systèmes d information. Vient en dernier dans notre liste. La perception de son importance varie beaucoup selon le pays : le plus élevé aux US. Un contrôle continu et outillé se fait très bien : SAM - Software Asset Management Ce «business case» est innovant. Il est au portefeuille des opportunités de projet Yphise pour la 1ere fois en Les solutions de SAM détectent les logiciels, mesurent leur utilisation, gèrent les licences, gèrent des politiques d utilisation des logiciels dans l entreprise, peuvent agir si un écart est identifié. 17

18 Merci Xavier Flez GM Gouvernance PR Projets IS Systèmes d Information SO Service Management 18