Hewlett-Packard

Audit et Sécurité des Systèmes d’information

ASSI v0.5.2

AWOUZOUBA ESSSO-ESSINAM

15/04/2015

2Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

I. Le gouvernement d'entreprise

Introduction

Les problèmes liés à l’informatique sont essentiellement des problèmes de logiciel

La crise du logiciel d’après travaux de Standish Group en 1995 permet de voir que sur 9380 projets étudiés, la situation est de moins appréciables telle que exemplifiée par le tableau ci-dessus :

Projets succès Problématique (hors budget hors délais, spécifications non fonctionnelles)

Echec /abandon

8380 16% 53% 31%

La gouvernance  d'entreprise - ou « corporate governance » - désigne le système formé par l'ensemble des processus, réglementations, lois et institutions destinés à cadrer la manière dont l'entreprise est dirigée, administrée et contrôlée.

En fonction des objectifs qui gouvernent l'entreprise, ce système est appelé à réguler les relations entre les nombreux acteurs impliqués ou parties prenantes. ( : stakeholders).

Les acteurs clés sont les actionnaires qui élisent le Conseil d'administration, lequel mandate la Direction, selon des modalités propres au régime juridique de ladite société. Les employés, les fournisseurs, les clients, les banques ou autres prêteurs, le voisinage, l'environnement et les tiers sont les autres stakeholders

1. Définition

La gouvernance du SI (SI :est un ensemble organisé de ressources (matériels, logiciels, personnel, données et procédures) qui permet de collecter, regrouper, classifier, traiter et diffuser de l'information dans un environnement donné) consiste d'abord à fixer au SI des objectifs liés à la stratégie de l'entreprise. Cette démarche permet de définir la manière dont le SI permet à l’entreprise de créer de la valeur en précisant le rôle des différents acteurs en tenant compte de leurs enjeux de pouvoir. Elle donne réponse à des questions telles que : la Direction des SI est-elle responsable de la mise en œuvre du SI ou est-ce le rôle des métiers ou des maîtrise d'ouvrage (MOA) ?

La gouvernance des SI ou gouvernance informatique (IT gouvernance) renvoie aux moyens de gestion et de régulation des SI mis en place dans une organisation en vue d'atteindre ses objectifs .. Les méthodes ITIL ( IT infrastructure library ) et COBIT sont par exemple des supports permettant de mettre un SI sous contrôle et de le faire évoluer en fonction de la stratégie de l'organisation.

Les SI font 15 à 20 % du chiffre d'affaires des entreprises, soit 50 % de la valeur ajoutée générée par les entreprises. Globalement, cela fait entre 20  à 25 mille milliards USD. Mais ce ne sont pas que des dépenses sans contreparties car une partie importante partie est constituée par des investissements qui permettent de développer la capacité de l'entreprise à créer de la valeur. Le développement des SI permet d'augmenter la valeur ajoutée créée par l'entreprise.

Le développement des SI représente des investissements conséquents qu'il faut gérer. Ce qui fait la réussite des entreprises à dominante de SI. C'est le concept de Peter Drucker d'IBO, Information Based Organization, utilisé par Google, Wall-Mart, Amazon, Dell, ....

3Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

2. Buts

La gouvernance des SI a pour but de définir les principaux objectifs, les fonctions et les tâches pour alimenter la nouvelle fonction du management de l'information. Il est pour cela nécessaire d'étudier et de proposer de nouvelles solutions, pour positionner cette nouvelle fonction dans l'architecture des modèles d'organisation et notamment de mettre en place des tableaux de bord des SI

La gouvernance des SI a l’enjeu de développer la capacité de l'entreprise à créer de la valeur basée sur 4 axes :

La création et le développement des services ( e-commerce, e-storage, e-services) La création de nouveaux produits (voitures électroniques, hybriques, photocopieurs) L'amélioration des processus de l'entreprise ( la gestion de la relation client ,CRM ; gestion de la

logistique, SCM : supply chain management ) Le développement des partenariats (clients, fournisseurs, concurrents)

3. Comment Gérer les investissements des SI ?Les SI nécessitent des investissements dans plusieurs domaines :

les infrastructures : serveurs, postes de travail, routeurs, etc. les applicatifs : logiciels de base, progiciels, applications spécifiques, etc. la mise en place du système : efforts sur la formation, capitalisation du savoir, etc. l'organisation et l'optimisation des processus existants.

4. Comment Piloter des SI? Un système d'information doit être piloté .Cela se fait sur la base de trois règles à savoir : Fixer des objectifs liés à la stratégie de l'entreprise, Lier les innovations permises par le SI en créant de nouveaux produits, des processus innovateurs ou

des services plus efficaces, Tenir compte de la valeur ajoutée créée par le système d'information par rapport aux dépenses

engendrées par la mise en place de celui-ci, ceci dans une optique long terme.

4Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

II. Urbanisation des SIIntroduction

L'urbanisation du SI d'une organisation consiste à faire évoluer le SI pour qu'il soutienne et accompagne efficacement et avec efficience les missions de cette organisation et leurs transformations. L'urbanisation du SI prend en compte l'existant et doit permettre de mieux anticiper les évolutions ou contraintes internes et externes impactant le SI, et en s'appuyant le cas échéant sur des opportunités technologiques. Il y a analogie entre l'urbanisation de l'habitat humain (organisation des villes, du territoire), et urbanisation informatique

L'urbanisation SI  réingénierie du  (SI) est l'action d'urbaniser le SI : cette démarche prévoit des principes et règles ainsi qu'un cadre cohérent, stable et modulaire, auquel les différentes instances décisionnaires de l'organisation peuvent se référer pour toute décision d'investissement relative au management du SI.

Les évolutions des stratégies d'entreprise (fusions, acquisitions, diversification des offres commerciales, e-commerce, CRM, nouveaux modes ou canaux de distribution, partenariats, réorganisation, externalisation, redéploiement des fonctions de back et front office, etc.) impliquent des changements structurels importants et accroissent l’interdépendance (dépendance mutualisée) et l’imbrication des applications informatiques avec le risque de renforcer l’effet « sac de nœud» du SI.

Cette complexité croissante a des conséquences sur les coûts, les durées et les risques des projets d’évolution des SI.

la démarche d’urbanisation des SI et par son prolongement au niveau de l’architecture des SI est la réponse à la maitrise progressive de l’évolution des SI en vue de réduire les coûts.

Cette démarche d'urbanisation vise un SI capable de soutenir et d’accompagner la stratégie d'entreprise dans le meilleur rapport coûts/qualité/délais. Elle permet d’améliorer la réactivité et de n’investir que dans les produits et services générateurs de valeur ajoutée, tout en maîtrisant les charges informatiques et le retour sur investissement.

1. Principe de l'urbanisation du SI

L'urbanisation répond à deux règles de base :

Une application doit appartenir-en cible- à un et un seul bloc (pour quelle raison ?). Les dépendances doivent respecter les notions de Cohérence Forte / Couplage Faible entre les applications, au sein d'une application : entre les différents modules, au sein d'un module : entre les différents composants.

Le terme -en cible- définit l'application que l'on cherche à avoir to be. Elle s'oppose à l'existant -la situation actuelle- As is. La méthode pour passer du as-is actuel au to-be souhaité est appelé la  ou feuille de route

La notion de Cohérence Forte / Couplage Faible indique que deux applications doivent communiquer entre elles de façon simple et efficace, mais que la dépendance entre ces deux applications est minimale (idéalement inexistante). Cela permet donc de retirer un bloc pour le remplacer sans perturber le reste du SI.

Le SI est comparable au quartier d'une ville  bien bâti et bien urbanisé, il est possible de raser un bâtiment au cœur du quartier sans mettre en péril tout le secteur, et de le remplacer ou de reconstruire un autre bâtiment, en raccordant ce nouveau bâtiment aux différents réseaux d'échanges : voirie d'accès, électricité, évacuation des eaux usées, etc. L'urbanisation consiste donc à créer un SI agile, modulable et évolutif.

5Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

2. Application des concepts d'urbanisation

L’urbanisation SI est une démarche d'aide à la transformation, rationalisation, simplification et amélioration du SI. Certains auteurs comparent le SI à l’image d’une ville, c'est-à-dire réfléchie, structurée, durable. Dans le prolongement de cette analogie - qui a toutefois des limites -, l'urbanisation du SI consiste à planifier des refontes structurantes pour optimiser, les échanges, les services, la flexibilité, la modularité ... et d'une façon plus générale à répondre à la stratégie SI de l'entreprise en parallèle de l'évolution du métier.

a) Le plan d'urbanisme SI ou Plan d'Occupation des Sols (POS)

Pour faciliter les planifications face aux évolutions du SI, l'urbanisation s'appuie sur un plan d'urbanisme appelé POS, en analogie avec l'urbanisme civil. Le POS consiste à représenter le SI en s’appuyant sur une cartographie fonctionnelle du SI et un découpage en capacités autonomes,: les zones, les quartiers, les îlots, ,briques

Le POS doit faciliter la construction d'une architecture optimisée du point de vue fonctionnel du SI qui est le point de vue pivot entre le point de vue du métier et le point de vue informatique.

Plus particulièrement, l’urbanisation vise :

à renforcer la capacité à construire et à intégrer des sous-systèmes d'origines diverses, à renforcer la capacité à faire interagir les sous-systèmes du SI et les faire interagir avec d’autres SI

(interopérabilité), à renforcer la capacité à pouvoir remplacer certains de ces sous-systèmes (interchangeabilité). favoriser son évolutivité, sa pérennité et son indépendance du SI, renforcer sa capacité à intégrer des solutions hétérogènes (progiciels, éléments de différentes plates-

formes).

b) Exemple de règles de découpage du SI Règle 1 : Séparation du Back-office du Front-office. Règle 2 : Découpage par processus et par métier. On crée ainsi les zones Décisionnel, Support et Métier.

( La zone Métier peut être découpée en plusieurs blocs.) Règle 3 : Séparation des canaux technologiques d'accès et de communication (site Web, notification

SMS, ...) des canaux du métier 'Relation Client' (CRM, Marketing). On inscrit deux nouvelles zones dans le Front-Office : Acquisition/Restitution et Relation avec les tiers.

Règle 4 : Il faut isoler ce qui est partagé par le Back-office et le Front-office ainsi que ce qui les intègre. On définit donc les zones Intégration et Données Partagées.

c) Les différents types de zones

En général, dans le découpage d'un SI on distingue différents types de zones :

Les zones des échanges avec l’extérieur du SI : acquisition/émission de/vers les partenaires : clients, fournisseurs,

Les zones des activités opérationnelles : gestion des opérations bancaires, gestion des opérations commerciales, gestion des opérations logistiques internes, etc. ;

Les zones de gestion des données de référence communes à l'ensemble du SI : les référentiels de données structurées (données clients, catalogue de produits et services, etc.) ;

Les zones de gestion des gisements de données : ensemble des informations produites quotidiennement, communes à l'ensemble du SI (données de production, etc.) ;

Les zones des activités de support : comptabilité, ressources humaines, etc. ; Les zones des traitements pour l’aide à la décision et le pilotage : informatique décisionnelle.

L’urbanisation totale et efficace des grandes entreprises demande le découpage du SI de l'entreprise en périmètres

autonomes ; par exemple : par grandes directions. Sa zone d'échange gère les flux extra-entreprises "SI ⇔ SI

extérieurs" que les flux intra-entreprises "SI ⇔ autres SI de l'entreprise".

6Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

3. Comment urbaniser ?

La démarche d’urbanisation suppose 3 axes clés imbriquées (qui s’alimentent mutuellement) :

la modélisation de la stratégie la cartographie des systèmes existants (métier, fonctionnels, applicatifs, techniques) la détermination des systèmes cibles (métier, fonctionnels, applicatifs, techniques)

La démarche d’urbanisation du SI consiste notamment à :

définir un SI cible, aligné sur la stratégie de l’entreprise, déterminer la trajectoire à suivre pour atteindre ce SI cible.

Indépendamment des différentes approches qui, selon le contexte de l'entreprise et les options méthodologiques, peuvent être préconisées les activités d'urbanisations se classent en cinq grands domaines :

Le "cœur" des processus d'urbanisme, Définir et maintenir le cadre d'urbanisme : plans d’urbanisme (cibles et scénarios de migration), règles, , Réaliser et maintenir l'infrastructure fonctionnelle du SI : référentiels d’entreprise, dispositifs mutualisés

d’échanges inter-applicatifs, …, Développer les relations avec les projets : cadrage, études amont, accompagnement des projets, … Les processus de support : notamment « Maintenir et diffuser les cartographies ». Et les processus de pilotage de l'urbanisation et de participation à l'arbitrage des projets.

7Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

III. AuditIntroduction

L'audit informatique (ou IT Audit) permet l’identification et l’évaluation des risques (opérationnels, financiers, de réputation notamment) associés aux activités informatiques d'une entreprise. L’audit se base sur le cadre réglementaire du secteur d’activité du pays concerné (ie le CRBF 97-02 pour une banque française), sur les référentiels de bonnes pratiques existants (ie le référentiel CobiT), sur les benchmarks à disposition et sur l’expérience professionnelle des auditeurs impliqués.

Il existe deux grandes catégories d’audit : Les audits globaux d'entité (audits des activités ayant trait aux systèmes d’informations et audits thématiques, ayant pour objectif la revue d’un thème informatique au sein d’une entité (la gestion de projet, la sécurité logique par exemple).

L’audit n’est pas l’activité de conseil qui vise à améliorer le fonctionnement et la performance d'une organisation avec une éventuelle implication dans la mise en œuvre de cette amélioration.

1. Les concepts de base de l'audit informatique

L’audit informatique se base sur La notion de contrôle. L'objectif est de mettre en place des dispositifs de contrôle efficaces et performants permettant de maîtriser l'activité informatique en vue de s’assurer de la réalisation raisonnable des trois objectifs suivants :

la conformité aux lois et aux règlements, la fiabilité des informations financières, la réalisation et l'optimisation des opérations (le champ de l’audit informatique).

La démarche d'audit informatique se définit à partir des préoccupations du demandeur d'audit (CEO,CFO,CIO),… Il va pour cela mandater l'auditeur pour répondre à une liste de questions précises qui font, plus ou moins implicitement, référence à l'état des bonnes pratiques connues dans ce domaine. Cela se traduit par un document important : la lettre de mission qui précise le mandat à exécuter et qui donne les pouvoirs nécessaires à l'auditeur.

L'auditeur informatique va se servir de référentiels d'audit informatique lui donnant l'état des bonnes pratiques dans ce domaine. CobiT: Val IT, Risk IT,  ISO 27002, CMMi, ITIL, …

2. Différents types d'audit informatique

La démarche d'audit informatique est générale et s'applique à différents domaines comme la fonction informatique, les études informatiques, les projets informatiques, l'exploitation, la planification de l'informatique, les réseaux et les télécom, la sécurité informatique, les achats informatiques, l'informatique locale ou l'informatique décentralisée, la qualité de service, l'externalisation, la gestion de parc, les applications opérationnelles… il existe les audits informatiques ci-après :

a. Audit de la fonction informatique

Le but de l'audit de la fonction informatique est de répondre aux préoccupations du (CEO, CIO) concernant l'organisation de la fonction informatique, son pilotage, son positionnement dans la structure, ses relations avec les utilisateurs, ses méthodes de travail…

8Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

Pour effectuer un audit de la fonction informatique on se base sur les bonnes pratiques connues en matière d'organisation de la fonction informatique. On peut citer :

la clarté des structures et des responsabilités de l'équipe informatique, la définition des relations entre la direction générale, les directions fonctionnelles et

opérationnelles et la fonction informatique, l'existence de dispositifs de mesures de l'activité (tableau de bord de la fonction informatique), le niveau des compétences et des qualifications du personnel de la fonction. le rôle des directions fonctionnelles et opérationnelles dans le pilotage informatique et

notamment l'existence d'un comité de pilotage de l'informatique, la mise en œuvre de politiques, de normes et de procédures spécifiques à la fonction, la définition des responsabilités respectives de la fonction informatique et des unités utilisatrices

concernant les traitements, la maintenance, la sécurité, les investissements, les développements,….

l'existence de mécanismes permettant de connaître et de suivre les coûts informatiques, soit à l'aide d'une comptabilité analytique, soit, à défaut, grâce à un mécanisme de refacturation,

le respect des dispositifs de contrôle interne comme une évaluation périodique des risques, la mesure de l'impact de l'informatique sur les performances de l'entreprise…

Ces différents objectifs de contrôle correspondent au processus PO 4 de CobiT : "Définir les processus, l'organisation et les relations de travail".

b. Audit des études informatiques (AEI)

L'AEI est un sous-ensemble de l'audit de la fonction informatique. Le but de cet audit est de s'assurer que son organisation et sa structure sont efficaces, que son pilotage est adapté, que ses différentes activités sont maîtrisées, que ses relations avec les utilisateurs se déroulent normalement,…

Pour effectuer un audit des études informatiques on se base sur la connaissance des bonnes pratiques recensées dans ce domaine. Parmi celles-ci on peut citer :

c. Audit de l'exploitation

L'audit de l'exploitation a pour but de s'assurer que les différents centres de production informatiques fonctionnent efficacement et qu'ils sont correctement gérés. Il est pour cela nécessaire de mettre en œuvre des outils de suivi de la production comme Openview d'HP, de Tivoli d'IBM, Nagios (GPL). Ce sont de SI dédiés à l'exploitation.

L’audit de l'exploitation s’appuie sur des bonnes pratiques concernant ce domaine :

la clarté de l'organisation de la fonction notamment le découpage en équipes, la définition des responsabilités,…

l'existence d'un SI dédié à l'exploitation notamment pour suivre la gestion des incidents, la gestion des ressources, la planification des travaux, les procédures d'exploitation,…

la mesure de l'efficacité et de la qualité des services fournies par l'exploitation informatique. la qualité de la planification de la production, la gestion des ressources grâce à des outils de mesure de la charge, des simulations, le suivi des

performances,…

9Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

l'existence de procédures permettant de faire fonctionner l'exploitation en mode dégradé de façon à faire face à une indisponibilité totale ou partielle du site central ou du réseau,

la gestion des incidents de façon à les repérer et le cas échéant d'empêcher qu'ils se renouvellent, les procédures de sécurité et de continuité de service qui doivent se traduire par un plan de

secours, la maîtrise des coûts de production grâce à une comptabilité analytique permettant de calculer

les coûts complets des produits ou des services fournis.

Ces objectifs de contrôle correspondent au processus DS 1, DS 3, DS 6, DS 12 et DS 13 de CobiT 

: DS 1 "Définir et gérer les niveaux de services", DS 3 "Gérer la performance et la capacité", DS 6 "Identifier et imputer les coûts", DS 12 "Gérer l'environnement physique", DS 13 "Gérer l'exploitation".

d. Audit des projets informatiques

L'audit des projets informatiques a pour but de vérifier le déroulement normal et l'enchaînement des opérations logiquement et efficacement en vue d’avoir de fortes chances d'arriver à la fin de la phase de développement à une application qui sera performante et opérationnelle.

Les bonnes pratiques pour effectuer un audit d'un projet informatique sont nombreuses et connues par tous les chefs de projets et de manière plus générale par tous professionnels concernés. On peut citer :

l'existence d'une méthodologie de conduite des projets, la conduite des projets par étapes quel que soit le modèle de gestion de projets : cascade, V, W ou

en spirale (processus itératif), le respect des étapes et des phases du projet, le pilotage du développement (les rôles du chef de projet et du comité de pilotage), la conformité du projet aux objectifs généraux de l'entreprise, la mise en place d'une note de cadrage, d'un plan de management de projet ou d'un plan

d'assurance qualité (PAQ), la qualité et la complétude des études amont : étude de faisabilité et analyse fonctionnelle, l'importance accordée aux tests, notamment aux tests faits par les utilisateurs. la clarté et l'efficacité du processus de développement, l'existence de procédures, de méthodes et de standards donnant des instructions claires aux

développeurs et aux utilisateurs, la vérification de l'application effective de la méthodologie, la validation du périmètre fonctionnel doit être faite suffisamment tôt dans le processus de

développement, la gestion des risques du projet. Une évaluation des risques doit être faite aux étapes clés du

projet.

Ces différents objectifs de contrôle correspondent aux processus PO 10, AI 1 et AI 2 de CobiT :

PO 10 "Gérer le projet" mais aussi AI 1 "Trouver des solutions informatiques" et AI 2 "Acquérir des applications et en assurer la maintenance".

e. Audit des applications opérationnelles (AAO)

10Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

Il couvre un domaine plus large et s'intéresse au SI de l'entreprise. Ce peut être l'audit de l'application comptable, de la paie, de la facturation,…. Mais, de plus en plus souvent, on s'intéresse à l'audit d'un processus global de l'entreprise comme les ventes, la production, les achats, la logistique,…

L'auditeur va s'assurer du respect et de l'application des règles de contrôle interne. Il va en particulier vérifier que :

les contrôles en place sont opérationnels et sont suffisants, les données saisies, stockées ou produites par les traitements sont de bonnes qualités, les traitements sont efficaces et donnent les résultats attendus, l'application est correctement documentée, les procédures mises en œuvre dans le cadre de l'application sont à jour et adaptées, l'exploitation informatique de l'application se fait dans de bonnes conditions, la fonction ou le processus couvert par l'application est efficace et productif,

Le but de l’AAO est de donner au management une assurance raisonnable sur son fonctionnement. Ces contrôles sont réalisés par le Commissaire aux Comptes dans le cadre de sa mission légale d'évaluation des comptes d'une entreprise : est-ce que le logiciel utilisé est sûr, efficace et adapté ?

Pour effectuer l'audit d'une application opérationnelle on va recourir aux objectifs de contrôle les plus courants :

le contrôle de la conformité de l'application opérationnelle par rapport à la documentation utilisateur, au cahier des charges d'origine et aux besoins actuels des utilisateurs,

la vérification des dispositifs de contrôle en place (données entrées, les données stockées, les sorties, les traitements,)… L'auditeur assure qu’ils existent et remplissent leur fonction

l'évaluation de la fiabilité des traitements se fait grâce à l'analyse des erreurs ou des anomalies qui surviennent dans le cadre des opérations courantes. Pour aller plus loin l'auditeur peut aussi être amené à constituer des jeux d'essais pour s'assurer de la qualité des traitements.

la mesure des performances de l'application pour s'assurer que les temps de réponse sont satisfaisants même en période de forte charge. L'auditeur va aussi s'intéresser au nombre d'opérations effectuées par le personnel dans des conditions normales d'utilisation.

Très souvent on demande à l'auditeur d'évaluer la régularité, la conformité, la productivité, la pérennité de l'application opérationnelle. Ce sont des questions délicates posées par le management à l'auditeur.

f. Audit de la sécurité informatique (ASI)

L'ASI a pour but de donner au management une assurance raisonnable du niveau de risque de l'entreprise lié à des défauts de sécurité informatique. On constate actuellement une augmentation de ces risques liée au développement d'Internet. Ils sont liés à la conjonction de quatre notions fondamentales :

En permanence il existe des menaces significative concernant la sécurité informatique de l'entreprise et notamment ses biens immatériels,

le facteur de risque est une cause de vulnérabilité due à une faiblesse de l'organisation, des méthodes, des techniques ou du système de contrôle,

la manifestation du risque. Tôt ou tard le risque se manifeste. Il peut être physique (incendie, inondation) mais en général, il est invisible et se traduit notamment par la destruction des données, détournement de trafic, etc..

la maîtrise du risque ( mettre en place des mesures permettant de diminuer le niveau des risques notamment en renforçant les contrôles d'accès, l'authentification des utilisateurs,…)

11Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

Pour effectuer un ASI il est nécessaire de se baser sur quelques objectifs de contrôle dont :

repérer les actifs informationnels de l'entreprise. Ce sont des matériels informatiques, des logiciels et des bases de données. Il est pour cela nécessaire d'avoir des procédures de gestion efficaces et adaptées,

identifier les risques. Il doit exister des dispositifs de gestion adaptés permettant de surveiller les domaines à risque. Cette surveillance doit être assurée par un RSSI, un responsable de la sécurité informatique,

évaluer les menaces. Le RSSI a la responsabilité de repérer les principaux risques liés aux différents domaines du SI. Un document doit recenser les principales menaces,

mesurer les impacts. Le RRSI doit établir une cartographie des risques associés au SI. Il est alors envisageable de construire des scénarios d'agression et d'évaluer les points de vulnérabilité,

définir les parades. Pour diminuer le niveau des risques il est nécessaire de prévoir les dispositifs comme des contrôles d'accès, le cryptage des données, le plan de secours,…

Il existe de nombreux autres objectifs de contrôle concernant l'audit de la sécurité informatique qui sont choisis en fonction des préoccupations et des attentes du demandeur d'audit.

Ces différents objectifs de contrôle correspondent aux processus de CobiT

DS 5 : "Assurer la sécurité des systèmes" et PO 9 "Evaluer et gérer les risques". Il existe un référentiel spécifique à la sécurité informatique :

ISO 27002. C'est un code des bonnes pratiques concernant le management de la sécurité des SI. Il est complété par la norme ISO 27001 concernant la mise en place d'un Système de Management de la sécurité de l'Information.

3. Démarche d'audit informatique

Une mission d'audit informatique se prépare par un pré-diagnostic afin de préciser les questions que cet audit va traiter. Cela se traduit par l'établissement d'une lettre de mission détaillant les points à auditer.

Pour mener à bien l'audit informatique il est recommandé de suivre les six étapes ci-après :

l'établissement de la lettre de mission faite par le demandeur d’audit et qui mandate l’auditeur. la planification de la mission permet de définir la démarche détaillée qui sera suivie. la collecte des faits, la réalisation de tests, … les entretiens avec les audités. la rédaction du rapport d'audit assorti des recommandations proposées, la présentation et la discussion du rapport d'audit au demandeur d'audit.

Il peut arriver qu'à la suite de la mission d'audit il soit demandé à l'auditeur d'établir le plan d'action et éventuellement de mettre en place un suivi des recommandations.

4. Les référentiels d'audit informatique

Il existe différents référentiels comme :

CobiT : C'est le principal référentiel des auditeurs informatiques, Val IT permet d'évaluer la création de valeur par projet ou par portefeuille de projets, Risk IT a pour but d'améliorer la maîtrise des risques liés à l'informatique CobiT and Applications Controls . ISO 27002 ,  un code des bonnes pratiques en matière de management de la sécurité des SI,

12Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

CMMi  : Capability Maturity Model integration qui est une démarche d'évaluation de la qualité de la gestion de projet informatique,

ITIL  . ITIL (Information Technology Infrastructure Library pour « Bibliothèque pour l'infrastructure des technologies de l'information ») est un ensemble d'ouvrages recensant les bonnes pratiques (« best practices ») du management du SI. Rédigée à l'origine par des experts de l'Office public britannique du Commerce (OGC), la bibliothèque ITIL a fait intervenir à partir de sa version 3 des experts issus de plusieurs entreprises de services telles qu'Accenture, Ernst & Young, Hewlett-

Packard, Deloitte, BearingPoint ouPriceWaterhouseCoopers. C'est un référentiel très large qui aborde les sujets suivants : Comment organiser un système d'information ? Comment améliorer l'efficacité du système d'information ? Comment réduire les risques ?

Comment augmenter la qualité des services informatiques ?

Le CobiT (en français Objectifs de contrôle de l’Information et des Technologies Associées) est un outil fédérateur qui permet d'instaurer un langage commun pour parler de la gouvernance des SI tout en tentant d'intégrer d'autres référentiels tels que ISO 9000, ITIL, 

. Le référentiel principal de gouvernance et d’audit des SI est le CobiT. En résumé le CobiT est un cadre de référence pour maitriser la gouvernance des SI dans le temps.

Le CobiT a été développé en 1994 (et publié en 1996) par l’ISACA (Information Systems Audit and Control Association). L’ISACA a été créé en 1967 et est représenté en France depuis 1982 par l’AFAI (Association Française de l’Audit et du Conseil Informatiques). C'est un cadre de contrôle qui vise à aider le management à gérer les risques (sécurité, fiabilité, conformité) et les investissements.

CobiT v 4.1 est une approche orientée processus, qui regroupe en quatre domaines (planification, construction, exécution et métrologie, par analogie avec la Roue de Deming), 34 processus distincts qui comprennent en tout 215 activités et un nombre plus important encore de « pratiques de contrôle ». Un volet "évaluation des systèmes d'information", connu sous le nom de Val IT tente de compléter cette approche.

La version 5 de COBIT est disponible depuis avril 20121. Cette version apporte des modifications importantes. Les niveaux de maturité ont été ajustés et sept facilitateurs font leur apparition. De plus, un ensemble de guides venant appuyer le référentiel sont publiés (mise en œuvre, sécurité...).

"Le CobiT" consiste à décomposer tout système informatique en :

Planification et organisation Livraison et support

Planification et Organisation : dans ce domaine nous cherchons à savoir comment utiliser les techniques informatiques afin que l’entreprise atteigne ses objectifs.

Définition du plan stratégique informatique, de l'architecture des informations, de la direction technologique

Organisation du service informatique Gestion des investissements et RH Communication des objectifs de la direction et Respect des exigences légales Évaluation des risques Gestion des projets et de la qualité Acquisition et Installation : ici CobiT cherche à définir, acquérir et mettre en œuvre des technologies

en les alignant avec les processus métiers de l’entreprise. Identification des solutions automatiques Acquisition et maintenance des applications informatiques

13Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

Acquisition et maintenance de l'infrastructure technique Développement et maintien des procédures Installation et certification des systèmes Gestion des modifications

Livraison et Support : l’objectif est de garantir l’efficacité et l’efficience des systèmes technologiques en action.

Définition des niveaux de service Gestion des services aux tiers et des performances et des capacités Garantie de la poursuite des traitements et de la sécurité des systèmes Identification et attribution des coûts Formation et Assistance des utilisateurs Gestion de la configuration, des incidents, données et des applications Sécurité physique du système Gestion de l'exploitation Monitoring : Il convient ici de vérifier que la solution mise en place est en adéquation avec les besoins

de l’entreprise dans une vision stratégique. Surveillance des processus Appréciation du contrôle interne Certification par un organisme indépendant Audit par un organisme indépendant

Le CobiT s’adresse à différents utilisateurs : Le management pour lequel il offre un moyen d’aide à la décision Les utilisateurs directs pour lesquels il permet d’apporter des garanties sur la sécurité et les contrôles

des services informatiques. Les auditeurs et les consultants auxquels il propose des moyens d’interventions reconnus

internationalement.

5. Le package CobiT 4.1

Il comprend 6 publications :

1. Executive summary (résumé de la vue d’ensemble de la méthodologie CobiT pour les managers pressés)2. Framework (cadre de référence explicatif de la méthode, des domaines et processus)3. Control objectives (215 objectifs de contrôle : ces objectifs sont directement orientés vers le management et les

équipes responsables des services informatiques)4. Audit guidelines (le guide de l’audit) ; il s’agit de déceler, d’analyser et expliquer les failles d’un système et les risques

qui en découlent ainsi que de leur apporter des solutions.5. Implementation Tool Set (les outils de la mise en œuvre du CobiT)6. Management Guidelines (le guide du management). Celui-ci dispose d’un modèle de maturité pour évaluer, sur une

échelle de 5 degrés, le niveau d’évolution de chacun des processus. Ce guide propose un cadre de pilotage de type tableau de bord prospectif (balanced scorecard).

L’objectif est d’assurer l’adéquation durable entre les technologies, les processus métiers et la stratégie de l’entreprise.

a. Critères de l'information

Cette rubrique va intéresser la direction générale en indiquant ce que l'implantation d'un processus donné va apporter sur les informations (par exemple sur l'information décisionnelle). Ces critères sont :

14Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

efficacité : qualité et pertinence de l’information, distribution cohérente efficience : rapidité de délivrance confidentialité : protection contre la divulgation intégrité : exactitude de l’information disponibilité : accessibilité à la demande et protection (sauvegarde) conformité : respect des règles et lois fiabilité : exactitudes des informations transmises par le management

En améliorant l'information selon ces critères, l'organisation pourra atteindre plus facilement ses objectifs, cela ouvrira des nouvelles opportunités et améliorera la rentabilité.

b. Les ressources

Cette partie concerne plus le directeur des SI (DSI) ou responsable des SI (RSI), pour l'informer des ressources qui vont être impactées par le processus. Les différentes ressources sont :

les compétences : le personnel, efficacité des collaborateurs (internes et externes) les applications : ensemble des procédures de traitement l'infrastructure : ensemble des installations, Data Center… les données : informations au sens global (format, structure…) les techniques : équipement, logiciels, bases de données, réseaux…

c. Les processus

Destinés à l'attention du gestionnaire de processus, ils vont définir la structure des domaines, des processus et des tâches. Il faut savoir qu’un processus se définit comme un ensemble de tâches. Par exemple, le processus « comptable » intervient dans le domaine « administratif et financier » et se divise en activités telles que « la saisie de factures, l’édition de balance… ». CobiT propose un modèle de maturité pour chaque processus afin de le situer par rapport aux meilleures pratiques du marché. Le modèle comprend 6 niveaux (0 à 5).

Les facteurs clés de succès définissent les actions les plus importantes à entreprendre pour maîtriser les processus. Les indicateurs clés d’objectif permettent de savoir a posteriori si un processus a répondu aux objectifs (en termes de critères d’information). Enfin, les indicateurs clés de performance déterminent la qualité de fonctionnement d’un processus (capacité à atteindre les objectifs).

d. CobiT Quickstart

Cette version simplifiée de CobiT s’adresse principalement aux PME pour lesquelles les techniques informatiques ne représentent pas un enjeu stratégique mais simplement un levier dans leur stratégie de croissance. Elle se repose sur les hypothèses suivantes :

l’infrastructure informatique n’est pas complexe, entreprise de petite taille la tolérance aux risques est relativement élevée du fait de l’externalisation des tâches complexes, l’éventail des contrôles est peu étendu, la structure de commandement est simple. Cette version conserve de CobiT 30 processus sur les 34, et 62 objectifs de contrôle sur les 318. La mise en œuvre Quickstart comprend 6 étapes : Évaluer le bien-fondé c’est-à-dire déterminer si cette version est adaptée à l’entreprise ; Évaluer la situation actuelle à partir de collectes d’informations auprès des personnes clé et de

rapports d’audit ;

15Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

Déterminer la cible avec la définition de l’activité, des contraintes légales, et de la dépendance de l’entreprise vis-à-vis de la technologie ;

Analyser les écarts par l’examen des pratiques de contrôle et des facteurs clés de succès ; Définir les projets d’amélioration des processus Élaborer un programme intégré de mise en place de la gouvernance en tenant compte des besoins

immédiats de l’entreprise, des interdépendances entre les projets et des ressources disponibles.

Limites

Selon Georges Épinette, administrateur du CIGREF, la démarche d'appréhension de ce référentiel doit se faire intelligemment, notamment lorsqu'il s'agit du cycle de vie de la relation client-fournisseur 2. En effet, CobiT présente une relative indigence en matière : d'alignement du SI ; de gestion des risques et de sécurité

16Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

IV. Gestion des projets SILa méthode traditionnelle identifie cinq éléments de développement d’un projet (4 étapes plus le contrôle): initiation planification et design, exécution, contrôle finition

Les phases de développement d’un projet Typical development phases of an engineering project

i. initiationii. planning :i. Déterminer comment planifier (e.g. by level of detail or rolling wave);

ii. Définir le canevas;iii. choisir l’équipe de planification;iv. identifier les livrables et créer la segmentation du travail;v. identifier les activités a réaliser pour faire des livrables en réseau séquentiel logique

vi. estimer les pré-requis en ressources pour les activités;vii. estimer la durée et le coût des activités;

viii. élaborer le programme ;ix. élaborer le budget;x. gestion des risques;

xi. avoir le ok formel pour démarrer xii. . planning for communications and for scope management,

xiii. Identifier les rôles et les responsabilités,xiv. Déterminer quoi acheter pour le projet xv. holding a kick-off meeting and designxvi. exécution & construction

xvii. suivre & contrôler les systèmesxviii. complétion

Chaque projet est caractéristique et spécifique et unique.

Agile management or gestion agile de projet est une méthode itérative et incrémentale de gestion du

des activités du design et en ingénierie, technologie de l’information, et développement de nouveau produit ou service dans un environnement assez flexible, eg  agile software development. Cela demande des professionnels des domaines concernés avec l’apport des fournisseurs et des clients.

Il existe des liens entre lean techniques, Kanban  et Six Sigma. Les techniques Agile sont très utilisées dans les petits projets ou partie d’un grand programme ou sur des projets trop complexes pour le client pour qu’il puisse spécifier ses besoins avant le test du prototype.

C’est la seule technique qui implique activement le client (disponible) dans le développement du projet.

17Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

Le développement logiciel avec la méthode consiste en un ensemble de de méthode de développement dans lesquelles les solutions et les prérequis suvent un schéma de collaboration entre l’auto-arganisation , les équipes transversales, .Agile promeut lla palanification adaptative le développement evolutif , la livraison à temps l’amélioration ccontinue et la réponsé rapide et flexible aux changements qui surviennent

The Agile Manifesto, par en 2001 donne les traits du concept de développement Agile

Le Manifeste Agile In February 2001, 17 software developers (voir plus bas) met at the Snowbird resort in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan

Scrum (software development) - A holistic approach to development that focuses on iterative goals set by the Product Owner through a backlog, which is developed by the Delivery Team through the facilitation of the Scrum Master.Extreme Programming (XP) –or  Pair Programming this method uses small groups and has a highly prescriptive Test Driven Development (TDD) model.eXtreme Manufacturing (XM) - An agile methodology based on Scrum, Kanban and Kaizen that facilitates rapid engineering and prototyping.Crystal Clear (software development) - An agile or lightweight methodology that focuses on colocation and osmotic communication.Kanban (just in time) - A lean framework for process improvement that is frequently used to manage WIP within agile projects. The Kanban process improvement framework has been specifically applied to software development, as Kanban (development).PRINCE2 stands for Projects in Controlled Environments. Dealing with a bit of history, this method was first established by the Central Computer and Telecommunications Agency (It is now referred to as the Office of Government Commerce).It has since become a very commonly used project management method in all parts of the world and has therefore proven to be highly effective in various respects.

Le diagramme de Gantt (Harmonogram Adamieckiego1) est un outil utilisé (souvent en complément d'un réseau PERT) en ordonnancement et en gestion de projet et permettant de visualiser dans le temps les diverses tâches composant un projet. Il s'agit d'une représentation d'un graphe connexe, valué et orienté, qui permet de représenter graphiquement l'avancement du projet.

Le premier diagramme de ce type (appelé Harmonogram Adamieckiego) fut réalisé par l'ingénieur polonais Karol Adamiecki en 1896. Il l'a décrit en 1931, mais la langue de publication n'a pas permis la reconnaissance internationale de son idée. Pour cette raison, le concept a été nommé d'après Henry L. Gantt, ingénieur américain collaborateur de Frederick Winslow Taylor, qui a publié la description du diagramme en 1910.

Cet outil répond à deux objectifs : planifier de façon optimale ainsi que communiquer sur le planning établi et les choix qu'il impose. Le diagramme permet :

de déterminer les dates de réalisation d'un projet ;

d'identifier les marges existantes sur certaines tâches ;

de visualiser d'un seul coup d'œil le retard ou l'avancement des travaux.

18Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

priorité à la réalisation des fabrications dont la date de livraison est la plus rapprochée ;

priorité à la première commande arrivée ;

priorité aux fabrications dont la durée totale est la plus courte ;

priorité aux fabrications qui utilisent au moins une ressource critique ;

priorité aux fabrications qui disposent du minimum de marge globale.

La méthode PERT ( Program Evaluation and Review technique) est une méthode conventionnelle utilisable en gestion de projet, développée aux États-Unis dans les années 1950.

Elle est censée fournir une méthodologie et des moyens pratiques pour décrire, représenter, analyser et suivre de manière logique les tâches et le réseau des tâches à réaliser dans le cadre d'une action à entreprendre ou à suivre.

Le concept perfectionne l'outil Diagramme de Gantt (1910) et a suscité le développement de méthodes comme la « Méthode MPM » (ou méthode des potentiels et antécédents métra) développée par Bernard Roy (1958).

Critical chain project management (CCPM) est une méthode de planification de gestion et d’exécution de projet qui prend en compte les incertitudes inhérents aux gestions de projets, (physiques, humaines, et aptitudes physiques aussi bien que la gestion et le support technique) nécessaire pour exécuter les projets

CCPM est une application de la  théorie des contraintes (TOC) de Goldratt aux projets. Appliquent les trois premiers des pas du TOC la contrainte système pour tous les projets est identifié comme les ressources. Exploiter les contraintes, les tâches sur le chemin critique est une priorité sur les autres activités Finalement,

19Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

les projets sont planifiés et gérés pour s’assurer de la disponibilité des ressources quand doivent commencer les tâches critiques de la chaine, ce qui supplante les autres tâches de la chaine critique

Le plan du projet plan doit subir le nivellement de  ressources, et la plus longue chaine de séquence de contraintes liée aux ressources doit être identifiée comme chemin critique

Lean project management ou la standardisation est l’introduction en gestion de projet des concepts comme lean construction, lean manufacturing and lean. L’intérêt de lean management c’est la minimisation des pertes en créant plus de la valeur

20Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

V. MaintenanceLa maintenance du logiciel (ou maintenance logicielle) désigne les modifications apportées à un logiciel, après sa mise en œuvre, pour en corriger les fautes, en améliorer l'efficacité ou autres caractéristiques, ou encore adapter celui-ci à un environnement modifié (ISO/IEC 14764).

Figure 1 En spirale

Figure 2 En V

21Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

Conception architecturale comprend le Dossier définition du logiciel dossier d’architecture technique plan de tests

1. Processus

Cette norme internationale distingue six processus de maintenance logicielle : (L'implémentation ; L'analyse et la résolution de problèmes ; La modification du logiciel ; L'acceptation de la modification par le demandeur ; La migration et la mise à la retraite.)

la maintenance du logiciel, repose essentiellement un nombre de processus, d'activités et de règles :

La transition : la passation coordonnée du logiciel, de l'équipe de développement à l'équipe de maintenance ;

Les ententes de services applicatives ; La priorisation des requêtes de modification et des rapports de problèmes ; L'acceptation ou le rejet d'une demande de modification selon le travail et la complexité plus ou

moins grandes qu'elle implique; son renvoi à l'équipe de développement.

Le maintenanceur ne fait pas que corriger des défauts (bugs). Pourtant des études et des enquêtes indiquent depuis des années que plus de 80 % des efforts de maintenance sont consacrés à des interventions autres que

correctives (Pigosky 1997). Cette notion est perpétuée par des utilisateurs qui font état de problèmes alors qu'ils ont affaire, en réalité, à des améliorations fonctionnelles du logiciel.

Poids de la Maitenance

Répartition effort développement. Origine erreurs Coût de la maintenanceDéfinition des besoins 6% 56% 82%conception 5% 27% 13%codage 7% 7% 1%Intégration Tests 15% 10% 4%Maintenance 67% 10% 4%

Figure 3 Zeltowitz, De Marco

Les travaux du Dr.Meir Lehman de l'Imperial College de Londres, en 1969 aboutissent en 1997 à la formulation de huit règles de l'évolution d'un logiciel (1997).

i. La modification continue –les logiciels doivent être continuellement adaptés ou il deviendra de moins en moins satisfaisant

ii. La complexité croissante –comme le logiciel est modifié, il devient plus en plus complexe à moins que le travail soit effectué pour réduire la complexité

iii. Relation de l'organisation –le logiciel existe dans un cadre de personnes, la gestion, règles et objectifs de créer un système de vérifications et de balances qui formulent l'évolution du logiciel

iv. Les taux de travail invariant –au cours de la durée de vie d'un système, la quantité de travail est exécutée, elle est essentiellement la même comme facteurs externes au delà de contrôle de tout d’actioné de l'évolution.

v. La conservation de familiarité –les développeurs et les utilisateurs du logiciel doivent conserver la maîtrise de son contenu afin d'utiliser et d'évoluer une croissance excessive réduit la maîtrise et agit comme un frein

vi. La croissance continue –apparemment semblable à la première loi, cette observation indique que la croissance supplémentaire est également dictée par les contraintes de ressources qui est restreinte   la portée originale du système

vii. Diminution de qualité – la qualité du logiciel diminuera  à moins que des mesures sont prises pour le garder en accord avec les changements opérationnels

Le feedback système  –l'évolution de la fonctionnalité et la complexité du logiciel est régie par  multi-boucle, multi-niveau, multiparti de feedback système et montrent que la maintenance est un processus

22Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

évolutif et que les logiciels évoluent avec le temps en devenant de plus en plus complexes à moins qu'une action spécifique soit engagée pour en réduire la complexité.

E.B. Swanson a identifié trois catégories de maintenance : la corrective, l'adaptative et la perfective. Ces catégories ont été mises à jour par l'équipe de ISO/IEC 14764,

Maintenance corrective (palliative et curative) : modification d'un progiciel effectuée après livraison afin de corriger les défauts rencontrés.

Maintenance préventive (adaptative, perfective, conditionnelle) : modification en fonction de l’environnement d’utilisation, de l’efficacité et pour prévenir les bugs

Pour l'AFNOR par contre, la maintenance consiste précisément à assurer qu'un bien continue de remplir sa fonction correctement, non à l'améliorer.

2. Niveaux de maintenance

Les problèmes majeurs de la maintenance du logiciel sont d’ordre technique et managérial

Les problèmes de gestion sont : l'alignement sur les priorités de la clientèle ; le choix des employés ; le choix de l'entité chargée de la maintenance ; la justification de la valeur ajoutée et des coûts de l'équipe. Les problèmes techniques sont liés à l'insuffisance de la compréhension du logiciel ; de la documentation ; des tests ; de la mesure de la maintenabilité. Les MM du savoir-faire visent spécifiquement la maintenance du logiciel sont : le modèle de maturité (MM) de la maintenance du logiciel S3M (avril 2006) ; le modèle de maturité (MM) de la maintenance corrective (Kajko-Mattsson 2001).

Il existe cinq niveaux de maintenance qui sont fonction (du lieu, du personnel, du type de travaux, des travaux )

23Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

VI. Gestion des risques et des performances : Val ITLa gestion des risques IT est l’application de la gestion de risques aux IT. Le risque d’entreprise lié à l’usage, à la possession, à l’opération ou l’implication ou l’influence et l’adoption de l’IT dans une entreprise.The establishment, maintenance and continuous update of an ISMS provide a strong indication that a company is using a systematic approach for the identification, assessment and management of information security risks. Different methodologies have been proposed to manage IT risks, each of them divided in processes and steps. According to Risk IT, it encompasses not just only the negative impact of operations and service delivery which can bring destruction or reduction of the value of the organization, but also the benefit\value enabling risk associated to missing opportunities to use technology to enable or enhance business or the IT project management for aspects like overspending or late delivery with adverse business impact.Generally speaking, risk is the product of likelihood times impact (Risk = Likelihood * Impact)

The measure of an IT risk can be determined as a product of threat, vulnerability and asset values: Risk = Threat * Vulnerability * Asset (risque= menace*vulnérabilité*ressource) A more current Risk management framework for IT Risk would be the TIK framework: Risk =

((Vulnerability * Threat) / Counter Measure) * Asset Value at Risk IT Risk

L’environnement du risque

Cette étape est initiale dans la structure ISO ISO/IEC 27005 . les activités élémentaires sont prévues comme premier sous procédure de l’évaluation des risques selon NIST SP 800-30. Cette étape suppose l’obtention de toutes les informations sur l’organisation et la détermination des critères de base, du but et du canevas de la gestion des risques et l’organisation chargée de ces activités de gestion des risques. The purpose is usually the compliance with legal requirements and provide evidence of due diligence supporting an ISMS that can be certified. The scope can be an incident reporting plan, a business continuity plan.

Another area of application can be the certification of a product.

Criteria include the risk evaluation, risk acceptance and impact evaluation criteria. These are conditioned by:

Cadre légal et cadre de régulation the strategic value for the business of information processes stakeholder  expectations negative consequences for the reputation of the organization

Risk assessment

Risk Management is a recurrent activity that deals with the analysis, planning, implementation, control and monitoring of implemented measurements and the enforced security policy. On the contrary, Risk Assessment is executed at discrete time points (e.g. once a year, on demand, etc.) and – until the

24Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

performance of the next assessment - provides a temporary view of assessed risks and while parameterizing the entire Risk Management process. This view of the relationship of Risk Management to Risk Assessment is depicted in figure as adopted from OCTAVE.

Risk assessment is often conducted in more than one iteration, the first being a high-level assessment to identify high risks, while the other iterations detailed the analysis of the major risks and other risks.

According to National Information Assurance Training and Education Center risk assessment in the IT is :

A study of the vulnerabilities, threats, likelihood, loss or impact, and theoretical effectiveness of security measures. Managers use the results of a risk assessment to develop security requirements and specifications.

Le processus de l'évaluation des menaces et des vulnérabilités, connues et hypothétiques, pour déterminer la perte attendue et d'établir le degré d'acceptabilité pour les opérations du système.

Une identification des actifs d'une installation spécifique ADP, les menaces qui pèsent sur ces actifs, et la vulnérabilité de l'installation ADP à ces menaces.

• Une analyse des actifs et des vulnérabilités système pour établir une perte attendue de certains événements sur la base de probabilités estimées de la survenance de ces événements. Le but d'une évaluation des risques est de déterminer si les contre-mesures sont adéquates pour réduire la probabilité de perte ou de l'impact de la perte à un niveau acceptable.

Un outil de gestion qui fournit une approche systématique pour déterminer la valeur relative et la sensibilité des actifs d'installation de l'ordinateur, l'évaluation des vulnérabilités, l'évaluation des niveaux d'exposition aux risques perçus espérance de perte ou, l'évaluation des fonctions de protection existantes et alternatives de protection supplémentaires ou l'acceptation des risques et la documentation des décisions de gestion. Les décisions de mise en œuvre des fonctions de protection supplémentaires sont normalement basés sur l'existence d'un ratio raisonnable entre le coût / bénéfice de la sauvegarde et de la sensibilité / valeur des actifs à protéger

ISO 27005 framework

Risk assessment receives as input the output of the previous step Context establishment; the output is the list of assessed risks prioritized according to risk evaluation criteria. The process encompasses these steps:

Risk analysis=Risk identification+Risk estimation+Risk evaluation

The ISO/IEC 27002:2005 Code of practice for information security management recommends the following be examined during a risk assessment:

politique de sécurité, • organisation de la sécurité de l'information, • la gestion d'actifs, • la sécurité des ressources humaines, • la sécurité physique et environnementale, • communications et la gestion des opérations, • contrôle d'accès, • l'acquisition de systèmes d'information, le développement et la maintenance, • informations gestion des incidents de sécurité, • gestion de la continuité des affaires et • la conformité réglementaire. • L'identification des risques

25Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

•L'identification des risques indique ce qui pourrait provoquer une perte potentielle; les suivantes sont à identifier:

(1-assets, primary (i.e. Business processes and related information) and supporting (i.e. hardware, software, personnel, site, organization structure) 2-threats 3 -existing and planned security measures 4-vulnerabilities 5-consequences 6-related business processes)

The output of sub process is made up of:

The list of asset and related business processes to be risk managed with associated list of threats, existing and planned security measures

list of vulnerabilities unrelated to any identified threats list of incident scenarios with their consequences.

Estimation du Risque

There are two methods of risk assessment in information security field, qualitative and quantitative.

Purely quantitative risk assessment is a mathematical calculation based on security metrics on the asset (system or application). For each risk scenario, taking into consideration the different risk factors a Single loss expectancy(SLE) is determined. Then, considering the probability of occurrence on a given period basis, for example the annual rate of occurrence (ARO), the Annualized Loss Expectancy is determined as the product of ARO X SLE. It is important to point out that the values of assets to be considered are those of all involved assets, not only the value of the directly affected resource.For example, if you consider the risk scenario of a Laptop theft threat, you should consider the value of the data (a related asset) contained in the computer and the reputation and liability of the company (other assets) deriving from the lost of availability and confidentiality of the data that could be involved. It is easy to understand that intangible assets (data, reputation, liability) can be worth much more than physical resources at risk (the laptop hardware in the example). Intangible asset value can be huge, but is not easy to evaluate: this can be a consideration against a pure quantitative approach.

Atténuation des risques est une méthodologie systématique utilisée par la direction pour réduire la survenance du risque

Risk mitigation can be achieved through any of the following risk mitigation options: Risk Assumption. To accept the potential risk and continue operating the IT system or to implement

controls to lower the risk to an acceptable level Risk Avoidance. To avoid the risk by eliminating the risk cause and/or consequence (e.g., forgo certain

functions of the system or shut down the system when risks are identified) Risk Limitation. To limit the risk by implementing controls that minimize the adverse impact of a threat’s

exercising a vulnerability (e.g., use of supporting, preventive, detective controls) Risk Planning. To manage risk by developing a risk mitigation plan that prioritizes, implements, and

maintains controls Research and Acknowledgement. To lower the risk of loss by acknowledging the vulnerability or flaw and

researching controls to correct the vulnerability Risk Transference. Prendre une assurance pour compenser une perte éventuelle To transfer the risk by using other options to compensate for the loss, such as purchasing insurance.

Le référentiel Val IT est un ensemble structuré de pratiques clés de management liées à la gouvernance des SI. Cette dernière comporte deux volets : un aspect risques, qui conduit à des pratiques d'audit et à des référentiels de bonnes pratiques comme CobiT. Et un aspect performance peu outillé au début des années 2000.

Les concepteurs du référentiel CobiT (l'ISACA et son chapitre français l'AFAI), rapidement relayés par la structure ITGI (IT Governance Institute, associée en France à l'IGSI ou Institut de Gouvernance du SI, hébergé

26Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

par le CIGREF) ont donc tenté de compléter leur approche initiale en proposant un cadre d'analyse de la performance des investissements en technologies de l'information. Un volet consacré à la sécurité et dénommé Risk IT est censé compléter le triptyque.

Val IT offre à la Direction de l'organisation un ensemble de préconisations lui permettant d'évaluer et sélectionner les projets de développement du système d'information en fonction de leur valeur, d'une part, d'anticiper puis de suivre leur cycle de vie du point de vue économique ensuite et, par retour d'expérience, d'améliorer les méthodes employées pour l'évaluation a priori des nouveaux projets, dénommées dans ce référentiel business cases.

Objectifs et développement du référentiel

Le concept Val IT prend racine dans les travaux de l'AFAI du début des années 2000 visant à adapter certains concepts issus du tableau de bord prospectif (balanced Scorecard) à l'évaluation de la performance des systèmes d'information et à leur apport à la création de valeur par l'entreprise. Le problème de management à résoudre est le suivant :

Rapport du Standish Group, 50% des projets informatiques soit (4100) ne donnent pas les résultats attendus en termes de délais, coûts et fonctionnalités, quand il ne s'agit pas d'échecs purs et simples.

Souvent, les justifications économiques (business cases) accompagnant un projet de développement du SI, porté soit par une direction opérationnelle soit par le direction des SI, sont incomplètes voire inexistantes.

Dans les grandes structures plus de 100 projets doivent être simultanément sélectionnés puis suivis ce qui, en l'absence d'outils, limite l'efficacité du contrôle que devrait exercer la Direction Générale.

La première version structurée du référentiel Val IT a été éditée par l'IT Governance Institute en 2006 et comprend les guides :

ITGI, Enterprise Value : Governance of IT Investments, Rolling Meadows, 2006. Ce document de 32 pages présente les objectifs du référentiel, la notion de business case, son organisation en 3 processus et 40 pratiques de management. La deuxième partie détaille les pratiques en les mettant systématiquement en correspondance avec les processus du CobiT.

ITGI, Enterprise Value : Governance of IT Investments : The Business Case, Rolling Meadows, 2006 28p. ITGI, Enterprise Value : Governance of IT Investments: The ING Case Study, Rolling Meadows, 2006. Une version 2.0 du référentiel a été publiée en 2008. Le fondement du référentiel est: ITGI, Enterprise Value:

Governance of IT Investments: Getting Started with Value Management, Rolling Meadows, 2008. 116p.

On parle de trois domaines et de processus au lieu de processus et des pratiques de la version 1. Les pratiques sont pris comme sous-ensembles des nouveaux processus.

Les domaines du CoBIT

La gouvernance de la valeur ( GV ou Value Governance) a pour objectif de s'assurer que le concept de valeur est présent dans les pratiques de management de façon à assurer la cohérence avec les pratiques globales de gouvernance, à organiser le processus de décision, à fournir des directions et des indicateurs de choix des projets en portefeuille et à assurer l'apprentissage organisationnel par la vérification de l'atteinte des objectifs sur les projets terminés. Les processus de la version 2.0 sont :

i. VG1 : établir un leadership informé et impliqué,ii. VG2 : définir et mettre en place les processus

iii. VG3 : définir les caractéristiques des différents portefeuilles de projets (composition, poids relatifs...),

iv. VG4 : aligner et intégrer la gestion de la valeur dans la gestion financière de l'entreprise,

27Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

v. VG5 : établir une surveillance efficace de la gouvernance (et identifier les dérives),vi. VG6 : mettre en place un processus d'amélioration continue des pratiques.

La gestion de portefeuille (GP, ou PM pour Portfolio Management) vise à optimiser la création de valeur à travers la construction du portefeuille d'investissement. Il faut, notamment, identifier les ressources nécessaires à chaque projet, définir les seuils d'investissement, évaluer, classer puis sélectionner (ou rejeter) les projets à lancer, gérer globalement le portefeuille d'investissements en termes de risques et rentabilité, surveiller les performances et en rendre-compte. Les processus composant GP sont :

i. PM1 : établir une stratégie claire et définir la structure de la cible en termes d'investissements,ii. PM2 : déterminer les sources et la disponibilité des budgets,

iii. PM3 : gérer la disponibilité des ressources humaines,iv. PM4 : évaluer et sélectionner les programmes à financer,v. PM5 : monitorer et rendre compte de la performance des portefeuilles d'investissement,

vi. PM6 : optimiser la performance des portefeuilles par une revue régulière des opportunités et risques.

Enfin, la gouvernance des investissements (GI ou IM pour Investment Management) vise à assurer la rentabilité de chaque investissement ou "programme" lié aux technologies de l'information ( IT Enabled), pris isolément. Il s'agit d'améliorer les compétences des managers opérationnels dans : a) l'identification des exigences de leur métier, b) la capacité d'apprécier les approches alternatives, c) la définition, rédaction et maintien des business cases détaillés au long de la vie du projet, d) l'affectation des responsabilités et de la propriété du projet, e) de la gestion du cycle de vie complet du programme, retrait inclus, f) du suivi régulier de la performance et des comptes-rendus. On note :

i. IM1 : développer et évaluer le business case initial du programme,ii. IM2 : comprendre les implications des candidats-programmes,

iii. IM3 : développer le plan du programme,iv. IM4 : préparer le budget sur le cycle de vie complet,v. IM5 : construire le business case complet, détaillé,

vi. IM6 : lancer le programme et gérer sa vie,vii. IM7 : mettre à jour les portefeuilles opérationnels,viii. IM8 : mettre à jour le business case à mesure de l'acquisition d'informations nouvelles,

ix. IM9 : monitorer le programme et rendre-compte,x. IM10 : procéder au retrait du programme en fin de vie.

Le business case

i. Quatre questions guident la construction du business case (4 Ares en anglais):ii. Faisons-nous les choses appropriées (are right things) ?

iii. Faisons-nous les choses de façon appropriée (are the right way) ? iv. Les tâches sont-elles effectuées correctement (are done well) ? Planification, budgets...v. En tirons-nous les bénéfices attendus ?

Le business case contient donc des éléments sur les résultats attendus (outcomes), aussi bien immédiats que différés, sur les actions (initiatives) et leurs impacts directs sur les résultats, les contributions ou impacts indirects croisés entre actions et résultats de nature différente et, enfin, les hypothèses sous-jacentes aux points précédents et qui permettent d'évaluer le risque du programme. La construction du business case comporte 8 phases dont 4 peuvent être menées en parallèle :

Collation de toutes les informations jugées pertinentes sur le programme,

28Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

Analyse de l'alignement stratégique (objectifs du programme rapportés à la stratégie de l'organisation), en parallèle avec la détermination des bénéfices financiers, des bénéfices non financiers (image...) et une analyse des risques du projet.

Approbation des éléments et optimisation en termes rendement - risques. Enregistrement des résultats d'analyse et rédaction de la documentation du cas. Revue régulière du cas pendant toute l'exécution du programme, en tenant compte de tous ses

impacts, y compris retardés.

Les quatre questions à se poser lors de sa création

Les questions fondamentales

1. La question stratégique : Faisons-nous ce qu’il faut ?2. L’investissement : 1- se conformer à notre vision, 2-correspondre aux enjeux métier, 3-contribuer à

l’atteinte des objectifs stratégiques 4 créer la valeur optimale à moindre coût avec peu de risques3. La question architecture : Le faisons-nous comme il faut ?4. L’investissement : 1-doit être conforme à architecture, 2-correspondre aux principes d’architecture,

3-contribuer valoriser notre architecture 4 être conforme aux architectures

À propos de la valeur fournie par les SI

La question de la réalisation : Le faisons-nous faire comme il faut ?Disposons-nous :

D’un management efficace et rigoureux De processus de gestion des réalisations et des modifications efficace De moyen techniques et métier suffisants et disponibles pour proposer les compléments nécessaires La question de la valeur, les bénéfices sont : Une compréhension claire et partagée des bénéfices attendus Des responsabilités « métier » clairement établies pour la réalisation des bénéfices Des métriques pertinentes Un processus de réalisation de bénéfices efficaces

Limites

Enfin, L'éditeur Microsoft a récemment publié un comparatif de son propre référentiel MOF (Microsoft Operations Framework) avec le couple CobiT / Val IT : on y détaille l'impact des deux approches sur le succès des projets de développement en termes de gouvernance, maîtrise des risques et conformité.

29Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

VII. Benchmarking de la gouvernance SI La mise en œuvre de la gouvernance des SI repose sur l'application d'un certain nombre de bonnes

pratiques reparties en quatre domaines comme suit : La conception, Le fonctionnement et le pilotage des SI, Le pilotage des évolutions des SI, L'évolution des SI.

Ces bonnes pratiques sont par exemple : Un SI conçu par un professionnel (architecte ou un maître d'ouvrage). C'est un travail de conception

ou de re-conception de l'organisation. Un SI doit permettre d’augmenter les volumes traités et de réduire les coûts unitaires des opérations. Un SI doit être piloté par un responsable qui doit avoir une autorité suffisante pour prendre les

mesures qui s'imposent. C'est particulièrement le cas d'un SI concernant un processus. Chaque SI doit disposer d'un tableau de bord permettant de suivre les évolutions et le cas échéant de

prendre des mesures correctrices.

Un suivi des anomalies constatées dans le cadre de l'utilisation normale du SI doit permettre de répertorier les dysfonctionnements et de les corriger en appliquant des règles de contrôle interne.

Piloter les évolutions du SI et les planifier dans le temps pour éviter des changements difficiles à gérer.

La connaissance de ces bonnes pratiques permet d'évaluer le degré de maturité d'un système d'information et d'établir un plan d'action adapté. Cette démarche repose sur les étapes suivantes :

Effectuer un audit du système d'information. Identifier les actions possibles. Déterminer les priorités. Fixer les responsabilités et les budgets d’investissement

30Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

VIII. Gestion Performance La gestion de la performance permet aussi aux organisations de mieux communiquer leurs buts communs et opérationnels. En effet, lorsque la performance atteint son plus haut niveau, l’entreprise peut bénéficier d’une panoplie d’avantages tels qu’une augmentation du revenu de l’organisation, une amélioration des liens interpersonnels entre les membres ainsi que la simplification des tâches des dirigeants en implantant un système de contrôle. De plus lorsqu'une entreprise réalise une augmentation importante de ses revenus, il est évident que tous ses membres peuvent y bénéficier. 

Le lien entre la performance de l’organisation et la performance individuelle est crucial. Prenez l’autoroute de l’exécution du haut vers le bas et du bas vers le haut. L’histoire de l'exécution de la stratégie ne finit jamais. Faites votre stratégie facile à retenir ... et à communiquer! 

Le manager, un vrai héro de la performance

Figure 4top three objectives are related to customers priorities of the high performers

Figure 5high performers are further along in their transition to private and public cloud

31Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

32Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

IX. Audit de sécuritéL'audit de sécurité d'un (SI) est une vue à un instant T de tout ou partie du SI, permettant de comparer l'état du SI à un référentiel.

L'audit répertorie les points forts, et surtout les points faibles (vulnérabilités) de tout ou partie du système. L'auditeur dresse également une série de recommandations pour supprimer les vulnérabilités découvertes. L'audit est réalisé de pair avec une analyse de risques, et par rapport au référentiel. Le référentiel est généralement constitué de :

la politique de sécurité du système d'information (PSSI)

la base documentaire du SI réglementations propre à l'entreprise textes de loi documents de référence dans le domaine de la sécurité informatique

1. L'audit est effectué dans différents buts :

réagir à une attaque se faire une bonne idée du niveau de sécurité du SI tester la mise en place effective de la PSSI tester un nouvel équipement évaluer l'évolution de la sécurité (implique un audit périodique)

L’audit a pour but de vérifier la sécurité. Dans le cycle de sécurisation, la vérification intervient après la réalisation d'une action. Par exemple, lors de la mise en place d'un nouveau composant dans le SI, il est bon de tester sa sécurité après avoir intégré le composant dans un environnement de test, et avant sa mise en œuvre effective. La  roue de Deming illustre ce principe.( Plan Do Check Act)

Le résultat est le rapport d'audit qui donne la liste exhaustive des vulnérabilités recensées par l'auditeur sur le système analysé et une liste de recommandations en vue de supprimer les vulnérabilités trouvées.

L'audit n’est pas l'analyse de risques. Il ne permet que de trouver les vulnérabilités, mais pas de déterminer si celles-ci sont tolérables. Au contraire, l'analyse de risque permet de dire quels risques sont pris en compte, ou acceptés pour le SI. L'auditeur dresse donc des recommandations, que le client suivra, ou pas. Le client choisit les recommandations ou non à suivre, en se référant à la politique de sécurité.

2. Pratiques de l’audit :

Interviews – tests d’intrusion – relevés de configuration –audit du code

a. Interview Le directeur des SI (DSI) les responsables de la sécurité des SI (RSSI) Les administrateurs Les utilisateurs du SI, qu'ils aient un rôle dans la production de l'entreprise, dans la gestion, ou la

simple utilisation des moyens informatiques Tout autre rôle ayant un lien avec la sécurité

33Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

b. Les tests d'intrusion

Ils sont de 3 types : Les tests boîte blanche, les tests boîte grise et les tests dits boîte noire.

Collecte d'informations publiques : pages web, informations sur les employés, entreprise ayant un lien de confiance avec la cible.

Identification des points de présence sur internet. et Ecoute du réseau.

c. Les relevés de configuration le chargeur de démarrage, les mécanismes d'authentification (password power, système d’authentification :,..), le système de fichiers (droits d'accès, utilisation de chiffrement, WEP, RSA, SHA...), les services, la journalisation, la configuration réseau,

d. L'audit de code

L’audit de code est une pratique consistant à parcourir le code source d'un logiciel afin de s'assurer du respect de règles précises. Notamment, les dépassements de tampon (buffer overflow), les bugs de format, ou pour une application web, les vulnérabilités menant à des injections SQL...

(une mémoire tampon, ou  buffer, est une zone de la mémoire vive ou de disque utilisée pour entreposer temporairement des données, notamment entre deux processus ou matériels ne travaillant pas au même rythme.)

3. Fuzzing

Pour les applications boite noire, où le code n'est pas disponible, il existe un pendant à l'analyse de code, qui est le fuzzing. Cette technique consiste à analyser le comportement d'une application en injectant en entrée des données plus ou moins aléatoires, avec des valeurs limites. Contrairement à l'audit de code qui est une analyse structurelle, le fuzzing est une analyse comportementale d'une application.

Le mot processus vient du latin pro (au sens de « vers l'avant ») et de cessus, cedere (« aller, marcher ») ie, avancer. La procédure  désigne plutôt la méthode d’organisation, la stratégie du changement.

34Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

X. La sécurité des SI (SSI) est l’ensemble des moyens techniques,

organisationnels, juridiques et humains nécessaire et mis en place pour conserver, rétablir, et garantir la sécurité du SI, une activité qui incombe au management du SI

Enjeux de la sécurité des SI « Le SI représente un patrimoine essentiel de l'organisation, qu'il convient de protéger. La sécurité informatique consiste à garantir que les ressources matérielles ou logicielles d'une organisation sont uniquement utilisées dans le cadre prévu "

Plusieurs types d'enjeux doivent être maîtrisés :

L'intégrité : Les données ne doivent pas être altérées de façon fortuite, illicite ou malveillante. La confidentialité : Seule les personnes autorisées ont accès aux informations La disponibilité : Le système doit fonctionner sans faille durant les plages d'utilisation prévues, garantir

l'accès aux services et ressources installées avec le temps de réponse attendu. La non-répudiation et l'imputation : Aucun utilisateur ne doit pouvoir contester les opérations qu'il a

réalisées dans le cadre de ses actions autorisées, et aucun tiers ne doit pouvoir s'attribuer les actions d'un autre utilisateur.

L'authentification : L'identification des utilisateurs est fondamentale pour gérer les accès aux espaces de travail pertinents et maintenir la confiance dans les relations d'échange.

La sécurité informatique est un défi d'ensemble qui concerne une chaîne d'éléments : les infrastructures matérielles de traitement ou de communication, les logiciels (systèmes d'exploitation ou applicatifs), les données, le comportement des utilisateurs. Le niveau global de sécurité est fonction du niveau de sécurité du maillon le plus faible, les précautions et contre-mesures doivent être envisagées en fonction des vulnérabilités propres au contexte auquel le SI est censé apporter service et appui.

Deux types de dommages peuvent affecter le SI d'une organisation:

Les dommages financiers directs (reconstitution des bases de données qui ont disparu, reconfigurer un parc de postes informatiques, réécrire une application) ou indirects (par exemple, le dédommagement des victimes d'un piratage, le vol d'un secret de fabrication ou la perte de marchés commerciaux. Un Exemple concret (relativement difficile de les estimer), des sommes de l'ordre de plusieurs milliards USD ont été avancées suite à des dommages causés par des programmes malveillants comme le ver Code Red..

La perte ou la baisse de l'image de marque. Perte directe par la publicité négative faite autour d'une sécurité insuffisante (cas de l'hameçonnage par exemple) ou perte indirecte par la baisse de confiance du public dans une société. Par exemple, les techniques répandues de dé-facement (une refonte d'un site web) permettent à une personne mal intentionnée de mettre en évidence des failles de sécurité sur un serveur web.

Les conséquences peuvent aussi concerner la vie privée d'une ou plusieurs personnes, (ses coordonnées bancaires, photos, ses codes confidentiels). De manière générale, la préservation des données relatives aux personnes fait l'objet d'obligations légales régies par la Loi Informatique et Libertés.

Pour parer ces éventualités, les responsables de SI se préoccupent depuis longtemps de sécuriser les données. Le cas le plus répandu, et sans aucun doute précurseur en matière de sécurité de l'information, reste la sécurisation de l'information stratégique et militaire : Le Department of Defense (DoD) des États-Unis est à l'origine du TCSEC, ouvrage de référence en la matière. De même, le principe de sécurité multi-niveau trouve ses origines dans les recherches de résolution des problèmes de sécurité de l'information militaire.

Démarche générale

Pour sécuriser les systèmes d'information, la démarche consiste à :

évaluer les risques et leur criticité : quels risques et quelles menaces, sur quelle donnée et quelle activité, avec quelles conséquences ?

35Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

On parle de « cartographie des risques ». De la qualité de cette cartographie dépend la qualité de la sécurité qui va être mise en œuvre.

rechercher et sélectionner les parades : que va-t-on sécuriser, quand et comment ? Etape difficile des choix de sécurité : dans un contexte de ressources limitées mettre en œuvre les protections, et vérifier leur efficacité.

Méthodes d'attaque portant atteinte à la sécurité du SI

Destruction de matériels ou de supports Sabotage : Rayonnements électromagnétiques Brouillage : Écoute passive Interception de signaux compromettants  Cryptanalyse 

Vol de matériels :.Analyse de supports recyclés ou mis au rebut : ".Divulgation Hameçonnage  ou filoutage (Phishing) : désigne l'obtention d'information confidentielle en prétextant une fausse

demande ou en faisant miroiter un pseudo-avantage auprès d'un utilisateur ciblé. Chantage : menace exercée vis-à-vis d'une personne privée ou d'une organisation en vue d'extorquer une

information "sensible". Émission d'une information sans garantie d'origine, Canular (Hoax) Bombe : Programme dormant dont l'exécution est conditionné par l'occurrence d'un trigger ou date Virus  : Programme malicieux capable de faire fonctionner des actions nuisibles pour le SI , et éventuellement de

se répandre par réplication à l'intérieur d'un SI. Ver  : pour perturber et saturer les réseaux Piégeage du logiciel : Des fonctions cachées sont introduites à l'insu des utilisateurs à l'occasion de la

conception, fabrication, transport ou maintenance du SI Exploitation d'un défaut (bug) : Les logiciels - en particulier les logiciels standards les plus répandus- comportent

des failles de sécurité qui constituent autant d'opportunité d'intrusion indésirables Canal caché : Type d'attaque de très haut niveau permettant de faire fuir des informations en violant la politique

de sécurité du SI. Les menaces peuvent concerner 4 types de canaux cachés : Canaux de stockage, Canaux temporels, Canaux de raisonnement, Canaux dits de "fabrication".

Cheval de Troie  : C'est un programme ou un fichier introduit dans un SI et comportant une fonctionnalité cachée connue seulement de l'agresseur.

Réseau de robots logiciels (Botnet) : Les robots (nombreux) se connectent sur des serveurs IRC (Internet Relay chat) au travers desquels ils peuvent recevoir des instructions de mise en œuvre de fonctions non désirées.( envoi de spams, vol d'information, participation à des attaques de saturation ...)

Logiciel espion (spyware): est installé sur une machine dans le but de collecter et de transmettre à un tiers des informations sans que l'utilisateur en ait connaissance.

facticiel : logiciel factice disposant de fonctions cachées Saturation du Système informatique Perturbation : Vise à fausser le comportement du SI ou à l'empêcher de fonctionner comme prévu (saturation,

dégradation du temps de réponse, génération d'erreurs) Saturation : Attaque contre la disponibilité visant à provoquer un déni de service (remplissage forcé d'une zone

de stockage ou d'un canal de communication) Pourriel (spam) : Envoi massif d'un message non sollicité vers des utilisateurs n'ayant pas demandé à recevoir

cette information. Cet usage contribue cependant à la pollution et à la saturation des systèmes de messagerie. Faufilement : Cas particulier où une personne non autorisée franchit un contrôle d'accès en même temps qu'une

personne autorisée.

Évaluation des risques

Tenter de sécuriser un SI revient à essayer de se protéger contre les menaces intentionnelles et d'une manière plus générale contre tous les risques pouvant avoir un impact sur la sécurité de celui-ci, ou des informations qu'il traite.

Méthodes d'analyse de risque

Différentes méthodes d'analyse des risques sur le SI existent. Voici les trois principales méthodes d'évaluation disponibles sur le marché français :

36Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

la méthode EBIOS (Expression des besoins et identification des objectifs de sécurité), développée par l'Agence nationale de la sécurité des systèmes d'information (ANSSI) ; la méthode MEHARI (Méthode harmonisée d'analyse des risques), développée par le CLUSIF ; la méthode OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation), développée

par l'Université de Carnegie Mellon (USA).

Informations sensibles

Avant de tenter de se protéger, il convient de déterminer quelles sont les informations sensibles de l'entreprise, qui peuvent être des données, ou plus généralement des actifs représentés par des données. Chaque élément pourra avoir une sensibilité différente.

Les actifs contiennent aussi et surtout le capital intellectuel de l'entreprise, qui constitue un patrimoine informationnel à protéger. Il faut évaluer les menaces et déterminer les vulnérabilités pour ces éléments sensibles.

Critères de sécurité

La sécurité peut s'évaluer suivant plusieurs critères :

Disponibilité  : garantie d’accessibilité des données par les personnes autorisées. Intégrité  : garantie que les éléments considérés sont exacts et complets. Confidentialité  : garantie que seules les personnes autorisées ont accès aux éléments considérés. Traçabilité  (ou « Preuve ») : garantie que les accès et tentatives d'accès aux éléments considérés sont tracés et

que ces traces sont conservées et exploitables. Une fois les éléments sensibles déterminés, les risques sur chacun de ces éléments peuvent être estimés en

fonction des menaces qui pèsent sur les éléments à protéger. Il faut pour cela estimer : la gravité des impacts au cas où les risques se réaliseraient, la vraisemblance des risques (ou leur potentialité, ou encore leur probabilité d'occurrence). Dans la méthode EBIOS, ces deux niveaux représentent le niveau de chaque risque qui permet de les évaluer (les

comparer). Dans la méthode MEHARI, le produit de l'impact et de la potentialité est appelé « gravité ». D'autres méthodes

utilisent la notion de « niveau de risque » ou de « degré de risque ».

i. Menaces

Les principales menaces auxquelles un SI peut être confronté sont :

un utilisateur du système /personne malveillante  un programme malveillant : un sinistre (vol, incendie, dégât des eaux) :

ii. Objectifs

Une fois les risques énoncés, il est souhaitable de déterminer des objectifs de sécurité. Ces objectifs sont l'expression de l'intention de contrer des risques identifiés et/ou de satisfaire à des politiques de sécurité organisationnelle. Un objectif peut porter sur le système cible, sur son environnement de développement ou sur son environnement opérationnel. Ces objectifs pourront ensuite être déclinés en fonctions de sécurité, implémentables sur le système d'information.

Moyens de sécurisation d'un système

Conception globale

La sécurité d'un SI peut être comparée à une chaîne de maillons plus ou moins résistants. Elle est alors caractérisée par le niveau de sécurité du maillon le plus faible et repose sur :

la sensibilisation des utilisateurs aux problématiques de sécurité, (en awareness) ; la sécurité de l'information ;

37Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

la sécurité des données (très fondamentale), ( d'interopérabilité, cohérence des données en univers réparti ;)

la sécurité des réseaux ; des systèmes d'exploitation , des télécommunications

la sécurité des applications (dépassement de tampon), la sécurité physique, soit la sécurité au niveau des infrastructures matérielles

Politique de sécurité.

La sécurité des SI se cantonne généralement à garantir les droits d'accès aux données et ressources d'un système, en mettant en place des mécanismes d'authentification et de contrôle. Ces mécanismes permettent d'assurer que les utilisateurs des dites ressources possèdent uniquement les droits qui leur ont été octroyés.

La sécurité informatique permet aux utilisateurs d’être à l’aise cela présuppose une politique de sécurité, ie :

élaborer des règles et des procédures, installer des outils techniques dans les différents services de l'organisation (autour de l'informatique) ;

définir les actions à entreprendre et les personnes à contacter en cas de détection d'une intrusion ; sensibiliser les utilisateurs aux problèmes liés à la sécurité des systèmes d'informations ; préciser les rôles et responsabilités.

La politique de sécurité est donc l'ensemble des orientations suivies par une entité en matière de sécurité élaborée au niveau de la direction de l'organisation concernée, car elle concerne tous les utilisateurs du système.

Responsable de la sécurité du SI

Cela étant, en France, ce sont principalement les grandes sociétés, entreprises du secteur public et administrations qui ont désigné et emploient, des « responsables de la sécurité des SI ». Peu à peu, le management de la sécurité informatique s'organise en domaines ou sous-domaines des services informatiques ou d'état-major ; ils sont dotés de moyens financiers et humains et intègrent les contrats de plan ou de programmes de l'entreprise.

Modèles formels de sécurité

Afin d'atteindre une cible d'évaluation avec un bon degré de confiance (niveau E4 de TCSEC au minimum), nous définissons formellement le concept de sécurité dans un modèle dont les objectifs sont les suivants :

exprimer les besoins de sécurités intégrées dans un contexte informatique, fournir des moyens pour justifier que le modèle est cohérent, fournir des moyens permettant de convaincre que les besoins sont satisfaits, fournir des méthodes permettant de concevoir et d'implanter le système. Il existe plusieurs modèles formels de sécurité :

Le modèle de Bell-LaPadula (gestion d'accès par mandat, confidentialité, statique) modèle qui a été le plus utilisé pour vérifier la sécurité des SI. Les concepteurs de ce modèle ont démontré un théorème appelé  Basic Security Theorem(BST). De ce modèle furent dérivés d'autres modèles : celui de Biba (gestion d'accès par mandat, intégrité, statique), celui de Dion(gestion d'accès par mandat, confidentialité et intégrité, statique), de Jajodia et Sandhu (gestion d'accès par mandat, confidentialité, statique).

Le modèle de non-déduction (gestion d'accès par mandat, confidentialité, dynamique) modélisant le flux d'informations en utilisant des concepts de la logique. Les modèles de sécurité basés sur le principe de flux d'informations ont leur utilité dans le contrôle des accès indirects à l'information : ils mettent en évidence le problème des canaux cachés.

Le modèle HRU (gestion d'accès discrétionnaire) et ses dérivés, le modèle Take-Grant et le modèle SPM.

Plan de continuité d'activité]

Face à la criticité croissante des SI au sein des entreprises, il est aujourd'hui indispensable de disposer d'un plan de sécurisation de l'activité.

38Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

Ce plan se décline en deux niveaux distincts :

le plan de reprise d'activité (PRA) aussi appelé reprise « à froid » qui permet un redémarrage « rapide » de l'activité après un sinistre, avec restauration d'un SI en secours avec les données de la dernière sauvegarde

le plan de continuité d'activité (PCA) également appelé reprise "à chaud" qui, par une redondance d'infrastructure et une réplication intersites permanente des données, permet de maintenir l'activité en cas de sinistres majeur de l'un des sites.

Moyens techniques

De nombreux moyens techniques peuvent être mis en œuvre pour assurer une sécurité du SI

Contrôle des accès au système d'information  ; Surveillance du réseau : sniffer, système de détection d'intrusion ; Sécurité applicative : séparation des privilèges, audit de code, rétro-ingénierie ; Emploi de technologies ad hoc : pare-feu, UTM, (antivirus, anti-spam, anti-logiciel espion) ; Cryptographie  : authentification forte, infrastructure à clés publiques, chiffrement.

39Audit & Sécurité Des Systèmes d’Information 2014

AWOUZOUBA Esso-Essinam 90794666 cawouzouba@gmail.com

DATAGRAPHIE

http://about.zappos.com/our-unique-culture http://fr.wikipedia.org/wiki/%C3%89valuation_d%27entreprise http://it-ebooks.info http://personalexcellence.co/blog/map-of-consciousness/ http://www.Bestcours.com http://www.digitalworld.org.bd/event/matrix http://www.gelog.etsmtl.ca/publications/pdf/310.pdf

Http://www.lifehacks.com http://www.investopedia.com/terms/b/business-process-redesign.asp http://www.ismadonai.net/

http://www.nu.edu/ourprograms/schoolofengineeringandtechnology/ computerscienceandinformationsystems/programs/master-of-science-in-cyber-security-and-information-assuranc.html

http://www.portailrh.org/expert/fiche.aspx?p=459963 http://www.redeemer.ca/academics/departments/computerscience/studies.aspx http://www.scriptmag.com/features/spec-scripts-fail-failure-homework-part-5

http://www.the-performance-factory.com/fr/....5-elements-essentiels-c.....savoir-sur-la- stratégie-d-exécution/

http://www.tutorialspoint.com/java/index.htm http://www.w3schools.com/ http://www3.interscience.wiley.com/cgi-bin/jhome/5391/

www.skillsyouneed.com/ps/living-ethically.html April & Abran, Améliorer la maintenance du logiciel, Montréal, Loze-Dion éditeur, 2006 

Pigosky T.M., Practical Software Maintenance, New York, John Wiley & Sons, 1996  Bensoussan A., La maintenance des SI et le droit, Paris, Hermes, 1993, p. 236 Champy, J. et M. Hammer (1993). Reengineering the Corporation: A Manifesto for Business Revolution,

New York, Harper Business. Fayol, H. (1916). Administration industrielle et générale, Paris, Dunod. Gestion des services liés aux technologies de l'information, itSMF France, juin 2004 Gestion opérationnelle des services, OGC/TCO (traduction itSMF), juin 2005 Gortner, H. F., J. Mahler et J. Bell Nicholson (1994). La gestion des organisations publiques, Sainte-Foy,

Presses de l'Université du Québec. Gulick, L. et L. Urwick (dir.) (1937). Papers on the Science of Administration, New York, Institute of

Public Administration. Introduction à ITIL, Christian Nawrocki, ITPMS, août 2005

ISO 9001 - Qualité, Sécurité, Gouvernance, ITIL v2 & v3, CMMI [archive] Kernaghan, K., B. Marson et S. Borins (2001). L'administration publique de l'avenir, Toronto, Institut

d'administration publique du Canada. March, J. et H. Simon (1958 [1993]), Organizations, Cambridge, Blackwell.

Martin Fowler, Kent Beck, Refactoring: Improving the Design of Existing Code, Addison-Wesley Professional, 1999, 464 p.,(ISB N  0201485672)

Maslow, A. (1954). Motivation and Personality, New York, Harper Collins. OCDE (2005). Moderniser l'État : la route à suivre, Paris, Éditions OCDE.

S3M V3 - Améliorer la Maintenance du Logiciel, Loze_Dion, 2005, ISBN 2-921180-88-X  Taylor, F. W. (1911). Principles of Management, New York, Harper & Row.