SIE 2

1. SIE 2 Missions d’auditFormes et types

2. Types de missions • Techniquement, une mission d’audit informatique peut toucher tous les domaines d’un SI • On trouvera donc des missions orientées : • Audit des logiciels • Audit du Service Informatique • Audit des contrats • Audit de la sous-traitance • Audit réseau • Etc. • L’un des audits les plus importants actuellement est l’audit de la sécurité informatique et de la qualité

3. Exemples de missions d’audit 1- Service informatique 2- Développement et maintenance logicielle 3- MPAQ (Méthode et plan assurance qualité) 4- Maintenance

4. 1 - Service informatique • Toute entreprise informatisée (partiellement ou totalement) se trouve dans l’une ou plusieurs de ces situations  • absence des services et de compétences ; • absence des services mais compétences internes ; • utilisation de service(s) informatique(s) interne(s). • Dans ce dernier cas, les axes d’études touchent : • rôle du service et des membres ; • activité et relations avec les utilisateurs et décideurs ; • politique informatique de la direction et stratégie associée ; • budgets et finances.

5. 1.2 - Rôle du service • Ils existent 4 pôles qui gravitent autour du service : • la direction : résoudre et anticiper les attentes, besoins et problèmes informatiques ; • les utilisateurs actuels : fournir les moyens, résoudre les problèmes,former et assister ; • les utilisateurspotentiels : répondre aux attentes et besoins ; • les prestataires : fournir des demandes claires et réalistes, assister et fournir les moyens nécessaires. • Ces 4 catégories de personnes en relation avec le service informatique, ayant des besoins différents, sont des sources de conflits et de tensions.

6. 1.3 - Exemple de questionnement • Existe-t-il une définition des missions du service? • Existe-t-il un organisme du service informatique et de sa position dans l’entreprise ? SI oui est-il à jour ? Quelles en sont les responsabilités et dépendances hiérarchiques connues - reconnues? • Existe-t-il une définition formelle des rôles et fonctions ? • Existe-t-il un organe de contrôle du service et de son activité ? Quel est son rôle exact ? • Existe-t-il une (ou des) règle(s) de remplacement et d’évolution dans les rôles et fonctions ?Ce pour faire face aux cas de figures tels que : absence, départ, évolution des missions, évolution des compétences, évolution des outils et moyens, etc.

7. Génie logiciel : veille technologique, spécification, production, tests, implémentation ; Matériel : administration, investissement (recherche, sélection, proposition, achat, ...), mise en oeuvre, évolution et remplacement / suivi des performances ; Maintenance : logiciel / matériel, préventive/curative, moyens internes (outils, locaux, personnes, câblage, etc.) ; Relation avec les utilisateurs : formation (des informaticiens et des utilisateurs) recueil des expressions de besoins, recherche des besoins, etc. assistance, conseil recherches des compétences, définition des rôles utilisateurs, mise en place de correspondants ; Relation avec la direction : compte rendu et gestion du service, schéma directeur, politique informatique, politique sociale au sein du service informatique ; Relation avec les fournisseurs : recherche/sélection, contrat et cahier des charges, suivi et utilisation, gestions des conflits / légalisation ; Sécurité : données, humaine, matérielle, logicielle, locaux, maintenance, communication. Administration données, réseau, communication, serveurs, etc. Références législatives 1.4 - Activités du service (extraits)

8. 2 – Développement logiciel • Exemple d’analyse du formalisme et des méthodes de développement : • Cahier des charges • Cahier des spécifications techniques • Méthodes et outils de développement • Méthodes et protocoles de tests et recettes • Protocoles de maintenance, de contrôle et de suivi des logiciels • Protocoles d’installation et diffusion • Protocoles de formation des utilisateurs, des informations • Mise en expérience • Prise en compte des expressions de besoin, échanges avec les utilisateurs, demandeurs et décideurs • Etc.

9. 2.2 - Moyens matériels • Adaptation des moyens par rapport aux contraintes du cahier des charges (performances, délai,...) ; • Adaptation des moyens de développement à ceux d’exploitation ; • Pérennité du matériel par rapport aux développement à effectuer (évolution matériel et ses contraintes,...) ; • Contraintes imposées pour le matériel, prises en compte dans les développements ; • Intégrations des : • coûts, • charges supportées/supportables, • assurance, • maintenance matérielle ; • Sécurité matérielle de développement

10. AGL, SGBD, O/S traités et supportés, Langages (L3G,L4G,L5G) Outils spécifiques / internes, Progiciels associées à des langages de développements, Bibliothèques de développement, Outils de maquettage, Outils de prototypage, Outils de documentation. Etc. Couverture par chaque outil de l’ensemble des besoins ? Maîtrise de l’utilisabilité (utilisé, suivi, évoluant,...) ; la maintenabilité (facilité d’évolution, centre de réutilisabilité, portabilité ou adaptabilité,...) ; la lisibilité (lecture de la fonctionnalité, des dépendances, du squelette, etc.) la documentation (utilisateurs, maintenance, conception - programmation) à jour, archivée, accessible, lisible ; l’adéquation qualité, Etc. 2.3 - Moyens logiciels

11. 3 – Assurance qualité informatique • On s’inquiète dans cette phase d’audit des points suivants : • Inscription de l’informatique au PAQ et au MAQ • Utilisation de méthodes et normes internes / externes ; • Formation, information et documentation; • Procédures de MOQ pour toute nouvelle activité, règle, version logicielle ou matérielle, etc.

12. 3.2 – Exemples de questionnement • Existe-t-il des méthodes ? Pour quels acteurs ? Pour quelle couverture de l’activité informatique (du cycle de vie système/logiciel) ? • Existe-t-il un nombre réduit de méthodes et outils employés (UML, OMT, M/2, POO, etc.) ? • Couverture avec recouvrement : les méthodes recouvrent plusieurs secteurs et / ou disposent de points de jonctions et d’échanges. • Existe-t-il des documents de synthèse d’utilisation de ces méthodes ? • Existe-t-il des outils informatiques ? (facilité/rapidité de réalisation, attrait, cadre obligatoire) • Existe-t-il des formations (sur les méthodes) ? • Utilise-t-on des méthodes connues et utilisées ? • Dans une entreprise, si des méthodes sont utilisées, on peut avoir : • obligation d’usage (2 objectifs : certitude de forme et certitude de fond) ; • simplification la méthode en utilisant des “recettes” (parfois maison) : éléments de base de communication sans “blocage” de personnel (souvent pour l’extérieur); minimum vital d’étude pour “asseoir” un travail.

13. 4. Maintenance • DEUX aspects de la maintenance : technique et organisationnel. • Sur le plan technique, on distinguera : • Les niveaux : préventif, curatif, • Les tranches : matériel, logiciel, communications, sécurité, données. • Sur le plan organisationnel  : • remède aux incidents et pannes, • mise à niveau et « conservation » à niveau, • contrôle d’utilisation, de conformité, ... • optimisation, fiabilisation, • suivi des changements et parade aux incidents (actions de prévention) • délai d’intervention et de résolution des problèmes • mise en expérience et partage d’expérience

14. 4.2 – Exemple de questionnement • Possède-t-on un descriptif complet des éléments à maintenir (liste avec information, rôle,...) et leur état des lieux ? • Existe-t-il et utilise-t-on des règles de maintenance ? • Quels sont les documents de référence ? Comment sont-ils utilisés ? Corrigés ? Diffusés ? Etc. • Existe-t-il une veille technique et technologique ? • Existe-t-il des indicateurs de maintenance préventive ? Des plannings de cette maintenance ? Etc. • Gère-t-on les contrats externes ? Les coûts externes et internes ? • Le service et le domaine maintenance sont-ils inclus dans le PAQ ? Comment et par qui ? Quel service audite cela ? • Etc.

15. Cas particulier Audit de la sécurité informatique : Présentation de la notion de sécurité informatique et des éléments associés

16. Synthèse • Revoir le 1° cours d’introduction • Un constat en terme de sécurité informatique est souvent fait ainsi : • Les pertes informatiques sont le plus souvent pensées en terme de « Pertes matérielles, de plus en plus souvent en Pertes de données, etc. », c’est à dire pertes directes • Mais on omet trop souvent les pertes indirectes qui en découlent … • les pertes de trésorerie, de CA, d’affaires et contrats, • les conséquences pénales et juridiques (par exemple dans un cas de fiducie de données), • etc.

17. Un état d’esprit • La sécurité n’est pas une évidence; il faut étudier et penser aux risques possibles : • Besoin de sauvegardes, • Risque d’intrusions, de vols, ou de diffusions, • Risque naturels, • Etc. • Et les pondérer : • Tout le monde n’encourt pas les mêmes risques; • Les risques varient en fonction des périodes, de la configuration du système, du personnel, de la zone géographique, du métier, etc.

18. Une réalité des pertes Matérielles Coûts de remplacement, de réparation, d’expertise, dedéblaiement ou d’enlèvement, etc. des éléments matériels DIRECTES Immatérielles Coûts de remplacement, de réparation, d’expertise, dedéblaiement ou d’enlèvement, etc. des éléments immatériels Frais suppl. Mesures conservatoires permettant la remise en état dusystème en performances et fonctionnalités nécessaires, … Pertes biens Pertes de biens physiques (informatiques ou non), de fonds,savoir-faire, informations stratégiques, patrimoine, etc. Pertes expl. Pertes de marché, de marges, de revenus, de clients,d’image de marque, de contrats, etc. INDIRECTES Resp. Civ. RC suite aux préjudices causés à des tiers dans un cadrejuridique (enceinte géographique, juridique, technique,…) Autres Qualitatives, réglementaires, normatives, déontologiques,juridiques, etc.

19. Risques Typologie définie au sein des méthodes MEHARI et MARION développées par le CLUSIF (Club de la sécurité informatique français) • Risques A E M • Accidents • Erreurs • Malveillances • Conséquences DDP • Détériorations, • Dégâts, • Pertes.

20. Sécurité et sûreté • 2 concepts liés au même titre que sécurité et qualité • Les informations (éléments essentiels du SI) se doivent d’être en mode DICP • D comme disponibles • I comme intègres • C comme confidentielles • P comme pérennesP comme prouvées • La méthode d’audit • COBIT ajoute des critèresqualité et fiduciaire : • efficacité • efficience • conformité • fiabilité

21. Méthodes sécurités (quelques …) Source : étude comparative menée par le secrétariat du conseil du Trésor du Québec, en novembre 2001 Nota : depuis Melisa (M. Version 3) n’est plus maintenue ni diffusée

22. ITSEC/ITSEM (Information technology security evaluation criteria / methodology) Critères Communs/ CEM (Criteria Evaluation Methodology) Reconnaissance mutuelle des certificats : accord européen France, Allemagne, UK … au total 13 pays européens (tous niveaux) 13 pays Européens (tous niveaux) Reconnaissance mutuelle des certificats : accord mondial (aucun) 13 pays Européens + USA, Canada, Australie, Nvlle Zélande (niveaux EAL 1 à 4 uniquement) Situation à ce jour ITSEC : Juin 1991 (bibliothèque de remise à jour annuelle) ITSEM : Juin 1995 CC Version 1.0 : 1996 CC Version 2.0 : 1998 CC Version 2.1(ISO15408) : 1999 CEM Version 1.0 : 01/2000 Evolutions prévues Pas d’évolution au niveau du concept Sera maintenu par le centre français de certification (SCSSI , Service Central de Sécurité des Systèmes d’Information) Normes sécurité Pour s’assurer qu’un produit ou système fournit effectivement toutes les fonctions de sécurité nécessaires, il doit être soumis à une évaluation formelle basée sur des normes internationales rigoureuses et objectives définissant la méthodologie et les critères.

23. Aspects organisationnels Politique de sécurité – organisation Veille Mesures d’audit Procédures Recensement des actifs – conformité à la législation – sécurité du personnel Politique d’embauche Clauses de confidentialité, etc. Continuité d’activité Aspects logiques Contrôle d’accès Gestion des droits et mots de passe Etc. Développement et maintenance des systèmes – communication et management opérationnel Gestion des sauvegardes, des journaux, des erreurs Protection contre les codes « malicieux » Séparation des responsabilités Aspects physiques Sécurité physique et environnementale Périmètre de sécurité Contrôle d’accès physique Isolement des zones de livraisons et d’accès clients Alimentation électrique Obligation de rangement (bureau principalement) Etc. Norme ISO 17799

24. FIN