Maîtrise des risques dans les projets

Présentation au sujet: "Maîtrise des risques dans les projets"— Transcription de la présentation:

1 Maîtrise des risques dans les projets
René HANOUZ En introduction quelques mots sur le CLOUD COMPUTING RHANOUZ Cabinet d ’expertise en SSI

2 CLOUD COMPUTING ou HYPER CONNEXION
IPAD, IPHONE, …sont des « tablettes «  hyper connectées » par Wifi et par téléphonie 3G, elles fonctionnent grâce aux applications que l’utilisateur télécharge. Cette connectivité sert aux applications accessibles en réseau qui résident dans des serveurs distants : c’est le principe du CLOUD COMPUTING, cela devrait permettre à terme une consultation : à distance du DM du patient des bases de données de référence pour affiner son diagnostic des radios de son patient des médicaments équivalents : génériques Avec un confrère spécialiste en vision conférence ….

3 VERS UN MONDE INTERCONNECTE …
Dans une journée de travail nous perdons en moyenne une heure rien qu’a essayer de faire quelque chose. Exemples : l’armée du salut a déployé une architecture sur internet couvrant 118 pays pour connecter ses bénévoles, optimiser les approvisionnements et coordonner les activités de secours (attentats, inondations, …) L’école de médecine de Hanovre a mis en place une technologie sans fil qui permet de collecter et enregistrer en temps réel les données sur les affections des patients tout au long de leur séjour à l’hôpital. Le système est même capable d’annoncer : « le patient X attend le Dr Y en salle Z ».

4 VERS UN MONDE MEDICAL INTERCONNECTE
En Espagne on a crée une plate-forme globale reliant quelques praticiens avec un système d’agenda qui gère 9 millions de consultations par an. Chaque patient peut se rendre dans n’importe quel établissement de sa région en sachant que le praticien pourra consulter l’intégralité de son dossier médical à jour. Le projet TRISTAN (US) associe des équipements médicaux, des communications par satellite et une technologie de télégestion des dossiers médicaux qui permettent à des spécialistes du monde entier de prêter main forte aux médecins des îles lointaines : établissement du diagnostic ou interventions d’urgence.

5 RETOUR SUR TERRE : CLASSIFICATION DES RISQUES
Accidents pertes de services essentiels (coupure d’énergie, de réseau, incendie, dégâts des eaux, …) Erreurs erreurs de conception erreurs de développement erreurs d’utilisation des SI Malveillances accès non autorisés au SI, utilisation détournée des règles attaques virales, … fraudes informatiques (le chiffre réel reste caché) …

6 STATISTIQUES Européennes
Pourcentage d’événements déclarés A.E.M.I (Influence d’Internet)

7 UNE APPLICATION NON SÉCURISÉE
Outre la non qualité, cela revient à laisser « la porte de son appartement ouverte » il en résulte des conséquences en termes : DE PERTES FINANCIÈRES (détournements de fonds, business, …) DE PERTES COMMERCIALES (image =départ de clients, …) DE PROBLÈMES JURIDIQUES ( implication du dirigeant, …), DE RÉSULTATS ALÉATOIRES (sabotage immatériel, …), DE DÉSTABILISATION DE L’ORGANISATION, DU SERVICE (mécontentement des utilisateurs, …).

8 LES REFERENTIELS du marché
Objectif : Sécurité des projets et développements Objectif : SDSSI Basés principalement sur le référentiel INCAS Basés sur les référentiels MARION, MEHARI, ERSICAP… Système Existant Évaluation de la vulnérabilité et des risques du système déjà construit Système Futur Intégration de la Sécurité dans les projets et logiciels en construction Règle d’or : Ne pas chercher à faire tout avec l’un ou l’autre des référentiels « le futur n’est pas l’existant même si parfois il s’en inspire »

9 Manque de sécurité : Risques liés au PROCESSUS = démarche de construction du projet
Organisation de projet inadaptée Insuffisance de compétences Coûts des projets trop élevés, Délais trop longs, Non conformité aux besoins, Utilisateurs non satisfaits, Logiciel choisit difficile à maîtriser … Plateformes techniques non adaptées au développement du projet Base d’essai constituée uniquement de données d’exploitation réelle Non participation de l’exploitation à temps dans le projet Absence de formation prévue pour les utilisateurs Productivité médiocre des équipes de développement ….

10 Manque de sécurité : Risques liés au PRODUIT = Application
Fonctions de l’application non conformes aux besoins réels ou manquantes. Intégration de fonctions malveillantes (préparation de détournements ou de fraudes ou de destruction de données). Nombreuses erreurs et incidents à la mise en service décourageant les utilisateurs et se traduisant par un manque de confiance dans le nouveau système. Altérations programmées et progressives des données utilisées par l’application. Absences de fonctions de contrôles rendant permissif l’application aux intrusions et malveillances (utilisations détournées de son objectif) Absences de contrôles programmés de type : validation ou corrélation sur les données sensibles. Mécanismes de sécurité insuffisants ou inadaptés à la mise en production (chiffrement, altération des temps de réponse en période de pointe, …) Absences de fonctions et procédures de continuité de service adaptées à un mode dégradé ou au travail à domicile Absences de fonctions et procédures de sauvegardes et archivages adaptées au niveau de criticité de l’application …

11 POURQUOI UN PEU DE METHODE : MCP
ABSENCE DE METHODE DE CONDUITE DE PROJET = CONDUITE EN ETAT D’IVRESSE INDEPENDANT DE LA TAILLE ET L’IMPORTANCE DU PROJET LA TRAME DOIT ETRE RESPECTEE HELAS BEAUCOUP D’ENTREPRISE l’ONT OUBLIE …CERTES IL N’Y A PAS DE CONTRAVENTION MAIS LES DOMMAGES SONT SOUVENT CONSIDERABLES ET CACHES

12 POURQUOI UN PEU DE METHODE
Intégrer la sécurité dans la Méthode de Conduite de Projet, c’est un des moyens de garantir la prise en compte effective de la maîtrise des risque dans chaque phase du cycle de conception et de développement de l’application future, et d’être conforme à la réglementation et aux normes de qualité. - Les études préalables - Les phases de conception et de modélisation - Les phases de développement (phase de réalisation, tests, …) - Les phases d’installation et généralisation - Les phases de maintenance L’intégration de la maîtrise des risques sécurité  est un moyen de faire évoluer la culture, le contexte organisationnel et méthodologique des DSI

13 Cycle de vie d’un projet
On peut esquisser une comparaison avec notre cycle de vie Mise en exploitation = naissance de l’application Mise en exploitation Recette Naissance Rodage Bilans de contrôle Enfance Adolescence Real/test Généralisation Maturité E. Tech Dif.Organes Maintenance E. Fonct Dev.Cérébral Vieillesse Conception d’un nouveau système EP Embryonnaire Conception enfants EO Fin de vie Fécondation

14 MAITRISE DES RISQUES et SECURITE DES PROJETS

15 OBJECTIFS RÉDUIRE LES ACCIDENTS MAJEURS : Mesures de Détection
détecter les risques avant qu’ils ne surviennent (alarme, contrôle programmés, …) Mesures de Prévention Evaluer la vulnérabilité : les failles du SI , détecter les cyber menaces, … réduire la potentialité des risques Mesures de Protection réduire l’impact des risques établir la cartographie des impacts suivre les risques (tableaux de bords, plan d ’actions,…)

16 OBJECTIFS (suite) RÉDUIRE LES ERREURS
de conception des projets (concertation insuffisante avec la maîtrise d’ouvrage, …) de réalisation et tests des programmes et logiciels d’exploitation (processus d’enchaînement, …) RENDRE COMPLEXE ET RISQUÉE TOUTE TENTATIVE DE MALVEILLANCE (cybercriminalité, …)

17 EXEMPLES PROJETS ET APPLICATIONS
CONCEPTION Changement de direction générale d’une filiale + concertation insuffisante avec les utilisateurs sur le choix d’un progiciel de crédit, à amener à son abandon pertes 5 Millions d’Euros + démotivation du personnel ayant participé au projet Tests de logiciels industriels insuffisants, accidents de personnes RÉALISATION La démultiplication des forces de développement pour rattraper le retard a eu l’effet inverse et a porté nuisance à l’exhaustivité des tests, ce qui a généré des erreurs et par la suite des pertes de gros clients (manque à gagner : 124,30 Millions d’Euros) FONCTIONNEMENT en Exploitation Introduction de code malveillant dans une application comptable, avec complicité, modifications des montants de virements et détournement, pertes 6 Millions d’Euros.

18 EXEMPLES CYBERCRIMINALITE
Août 2003, trois spammeurs condamnés à payer un Milliard de dollars d’amende, un fournisseur de service avait vu ses serveurs noyés sous un flot de spam : 10 millions d’ s publicitaires par jour ! Juin 2009, plus d’une centaine de code d’accès au système de gestion des résultats du baccalauréat se sont retrouvés sur internet ! Avril 200,Atteinte au secret de fabrication vers la concurrence (entreprise Duracell) Janvier 2008, prise de contrôle du système de signalisation et d’aiguillage des tramways en Pologne ville de Lodz, deux trams sont entrés en collision et d’autres ont déraillés. Il faut avoir conscience que même à jour les anti-virus ne détectent que les virus connus et ne sont d’aucune utilité pour les nouveaux

19 QUELQUES PISTES POUR RÉDUIRE LES DÉFAUTS DU DEVELOPPEMENT
REVUES DES SPÉCIFICATIONS FONCTIONNELLES REVUES DE LA CONCEPTION DÉTAILLÉ TECHNIQUE TESTS UNITAIRES : jeux de tests programmes, REVUES DE FIN DE PROGRAMMATION : inspection de code, … TESTS D’INTÉGRATION Contrôle de l ’enchaînement des modules, jeux d’essais utilisateurs,… TESTS INTER-APPLICATION Fonctionnement des applications entres-elles, interfaces

20 QUELQUES PISTES POUR RÉDUIRE LES DÉFAUTS DU DEVELOPPEMENT
TESTS DE NON RÉGRESSION Vérifier qu ’après une modification ce qui marchait avant marche toujours TESTS FONCTIONNELS Contrôle de validité par rapport aux spécifications, relecture, inspection par d’autres analystes TESTS SUR SITE Satisfaction aux normes de l’exploitation, Validation des dossiers d’exploitation, fonctionnement à blanc, … TESTS DE PERFORMANCES Robustesse, sécurité, temps de réponse, plateforme d’essai, … AUDIT DE PROJET

21 CHAMPS de la Sécurité Projet
FLUX (échanges à travers les réseaux) PROCESSUS FONCTIONNELLES (règles de gestion, …) PROCEDURES (organisation métier : utilisateur) DONNÉES (le DICP des données) MATÉRIELS et RESEAUX (continuité de service) LOGICIELS (exhaustivité des fonctionnalités demandées)

22 PRINCIPE de la Maîtrise des risques
IDENTIFIER et CLASSIFIER, les risques susceptibles de se produire (Accident, Erreur, Malveillance) et EVALUER leur gravité (Impact et potentialité) DÉFINIR LES MESURES de REDUCTION des risques (besoins, services et mécanismes) LES VALIDER robustesse et pérennité réduction de l’impact du risque (Conséquences) réduction de la potentialité du risque (Efficacité des mesures) LES JUSTIFIER Au cours des phases du projet

23 LES CRITERES d’analyse du risque sécurité
Disponibilité Dn Intégrité In Confidentialité Cn Preuve et contrôle Pn Réglementation et Juridique Rn

24 LA GRADUATION de la gravité des risques
Stratégique n = 4 (Politique) Critique n = 3 (mise en cause de la continuité des activités) Sensible n = 2 (perturbation significative) INACCEPTABLE Faible n = 0 ou 1 ACCEPTABLE

25 LES ACTEURS dans un projet
L’équipe de projet Utilisateur (MOA) L’équipe de projet Informatique (MOE) Le qualiticien Le RSSI ponctuellement Les experts, selon les phases : Infrastructure et télécommunication Administrateur des données Gestionnaire des habilitations Spécialiste de la production ... Le contrôle : bilan qualité et sécurité

26 ACTIONS SECURITE PAR PHASE PROJET
Etude d’opportunité Ebauche : Identification des risques avérés sur le système existant (MOA – MOE) Etude préalable Analyse des risques du système futur Déclinaison des besoins sécurité du projet (MOE – MOA) Etude fonctionnelle et technique Mise en place des mesures de réduction des risques sécurité (MOE) Développement Encodage, tests et recette de la nouvelle application (MOE – MOA) Mise en production et généralisation Bilan et revue sécurité de l’application

27 La sécurité en Étude d’Opportunité

28 ACTIONS DE SÉCURITÉ EN PHASE : ÉTUDE D’OPPORTUNITÉ
Maîtrise des risques : SECURITE IDENTIFIER LES ACTIVITÉS METIERS DU SYSTEME EXISTANT ET ANALYSER LES RISQUES AVERES DICP(r) ET LEUR GRAVITE on ne retiendra pour l’analyse en étude préalable que ceux classés critiques

29 RECENSER LES RISQUES AVERES SUR L’EXISTANT
OBJECTIFS : Recenser les risques survenus et ce à quoi on a échappé pour être en mesure de les éviter dans le futur système. Définir la cible de sécurité DICP® du système futur. MOYENS : Connaissance du système existant par les utilisateurs. Résultats d’audit, rapports, questionnaire de vulnérabilité, etc. . RÉSULTATS : Liste des risques survenus et jugés inacceptables. Extrapolation « ce à quoi on a échappé ». D I C P existant cible

30 MODE D’EMPLOI : IDENTIFICATION DES ACTIVITES CRITIQUES DU PROJET
Question : QUE S’EST-IL PASSE sur le SE (Système Existant) Indisponible prolongée pour les utilisateurs métiers? Fourniture de résultat erronés, incomplets ou altérés ? Intrusion dans le SE par un tiers non autorisé ? Absence de traçabilité ? Non respect de la réglementation et des lois ? Faire ressortir les activités jugées critiques

31 La sécurité en phase d ’Étude Préalable

32 ACTIONS DE SÉCURITÉ EN PHASE ÉTUDE PRÉALABLE
RISQUES SUR LE DEVELOPPEMENT DU PROJET APPRÉCIER LES RISQUES LIÉS AU PROCESSUS PROJET. RISQUES SUR LE SF (Système Future) Analyse des RISQUES sur le projet FONCTIONNELS et TECHNIQUES PROGICIELS Détermination des Orientations et Mesures de réduction de la gravité des risques Synthèse sécurité : Expression des Besoins DICP de l’application future

33 RISQUES LIÉS AU DEVELOPPEMENT DU PROJET
AU DÉBUT DE CHAQUE PHASE DU PROJET, ANALYSE DES RISQUES DE DERAPAGE LIÉS : à la taille, au contexte organisationnel, à l ’environnement technologique et au savoir Outil : QUESTIONNAIRE ET UNE GRILLE D’ÉVALUATION

34 RISQUES LIÉS A LA TAILLE DU PROJET
1. MATRICE CHARGES / DÉLAIS : Exemple 2. NOMBRE DE DIRECTIONS CONCERNÉES (1, 2, 5 et plus)

35 CONTEXTE ORGANISATIONNEL
IMPACT SUR LES PROCÉDURES EXISTANTES. IMPACT SUR LA STRUCTURE ET L’ORGANISATION EXISTANTE. MOTIVATION DE L ’UTILISATEUR. PARTICIPATION DES UTILISATEURS. EXISTENCE D’UNE ÉQUIPE DE PROJET : UTILISATEURS -INFORMATICIENS.

36 ENVIRONNEMENT TECHNOLOGIQUE ET SAVOIR
ASPECTS MATÉRIELS ASPECTS LOGICIELS CONNAISSANCE INFORMATIQUE DES UTILISATEURS CONNAISSANCE DU METIER PAR LES UTILISATEURS CONNAISSANCE DU DOMAINE PAR LES INFORMATICIENS

37 SYNTHESE DES RISQUES LIÉS AU PROCESSUS PROJET
NOTE ET PONDÉRATION POUR CHAQUE QUESTION. LA NOTE GLOBALE EST POSITIONNÉE SUR UNE ÉCHELLE DE NOTATION DU RISQUE (de 57 à 250) PRÉCISANT LE NIVEAU DE RISQUE DU PROCESSUS PROJET 57 110 180 250

38 EXEMPLE D’OUTIL : MATRICE PONDEREE
Échelle de notation du niveau de risque Niveau de risque lié au développement du projet : faible sensible critique inacceptable Faible Sensible Critique Inacceptable 45 110 180 250

39 ANALYSE DES RISQUES DU SYSTÈME FUTUR
QUOI FAIRE ? Identifier pour les activités classées critiques : LES RISQUES liés aux FLUX, PROCESSUS, DONNÉES, et ARCHITECTURE TECHNIQUE en termes d’accidents, erreurs, malveillances Définir les ORIENTATIONS et MESURES DE SÉCURITÉ PERMETTANT DE RÉDUIRE LA GRAVITÉ DE CES RISQUES. Établir UNE SYNTHÈSE ET UN BILAN DE JUSTIFICATION RISQUES/MESURES.

40 ANALYSE DES RISQUES DU SF
COMMENT FAIRE ? POUR CHAQUE RISQUE MAJEUR RETENU par la MOA et la MOE Décrire le risque probable compte tenu de l’environnement, de l’organisation et de l’architecture technique prévue (Centrale, Distribuée, Internet, Cloud Computing, …). Décrire les conséquences de ce risque en terme d’impact et de potentialité,, et le type de préjudice subi,

41 CLASSIFICATION DICP® pour le flux de données virements
EXEMPLE : FORMALISME CLASSIFICATION DICP® pour le flux de données virements Entreprises et Particuliers virements D2 I3 C1 P2 R1 Gestion des crédits ON OBTIENT AINSI UNE CARTOGRAPHIE DETAILLEE DE LA GRAVITE DES RISQUES SUR LE SYSTEME FUTUR

42 EXEMPLE : ARCHITECTURE TECHNIQUE
Intranet Serveurs US Configuration Serveurs orient IBM – site central C2, P2 D 2 ,I 3 C3, P3 Firewall / chiffrement Les composants pour lesquels les risques détectés sont classés critiques sont mis en évidence et la valeur des facteurs DICP est mentionnée. SGBD UNIX WINDOWS INTERNET D1, I3, P3, C3 Bde Firewall / chiffrement IMP SERVEUR B. Données D 3 ETHERNET PW + carte PW + carte Hard copy C 2

43 MESURES DE SÉCURITÉ POUR LE SYSTÈME FUTUR
On les présente : Par typologie « D,I,C,P,R » le RISQUE en tenant compte des exigences de sécurité du SF : - Définir des ensembles de MESURES qui permettent de ramener les préjudices subis à un niveau jugé acceptable. - s’assurer de la faisabilité de mise en place Pour qu’un risque diminue il est recommandé de prendre des mesures de sécurité permettant de réduire à la fois : La potentialité du risque (sa fréquence de survenance) L’impact du risque (les conséquences et les préjudices subis).

44 FAISABILITE ET SUIVI DE MISE EN PLACE DES MESURES
POUR CHAQUE ENSEMBLE DE MESURES DE SÉCURITÉ : Indiquer dans quelle phase du projet les mesures doivent être prises en compte, Préciser la direction (ou le service) responsable de la mise en oeuvre des mesures, Estimer la cotation de la gravité résiduelle du risque, Valoriser (si possible) le coût des mesures, Indiquer les modalités de mise en place des mesures (organisationnelles, techniques, …).

45 Description du risque :
EXEMPLE DE FORMALISME Description du risque : Accès illicite à des informations confidentielles, il en résulte une publication d’information erronée dans la presse mettant en cause l’établissement sur un plan juridique et d’image. Conséquences : Atteinte à l’image de l’établissement, perte de clientèle à gros capitaux qui ne peut accepter de traiter avec un établissement dont l’image est entachée. Mise en cause possible du Directoire. Mesures recommandées : Stratégie : Contrôler que l’application des règles de confidentialité de base sont applicables à la nouvelle application (contrôle d’accès généralisé aux impressions et documents confidentiels, …) . Organisation : Mettre en place la séparation des pouvoirs pour les accès aux fichiers et documents sensibles Technique : Mettre en place un contrôle d’accès au système d’information (authentification forte : réseaux, serveurs, postes de travail, …), plus un système de trace (preuve et contrôle)

46 ANALYSE DE LA SECURITE DES LOGICIELS OU PROGICIELS RETENUS POUR LE SF
OBJECTIF : S’assurer que le ou les progiciels, logiciels prennent en compte les aspects essentiels de la sécurité. MOYENS : Documentation détaillée du progiciel analysé. Connaissance du domaine traité dans le projet. OUTIL : QUESTIONNAIRE SÉCURITÉ DES PROGICIELS.

47 QUESTIONNAIRE SÉCURITÉ DES PROGICIELS
Dans la cadre d’un choix de logiciel ou en complément, on déroulera UN QUESTIONNAIRE COUVRANT LES THÈMES : Adaptation du progiciel ou logiciel à l’environnement applicatif et/ou matériel Les dispositifs de sécurité du progiciel lui-même. La sécurité de l’application traitée par le progiciel

48 QUESTIONNAIRE PROGICIELS : ADAPTATION A L ’ENVIRONNEMENT
EXEMPLES

49 QUESTIONNAIRE PROGICIELS : SÉCURITÉ DES PROGICIELS
EXEMPLES :

50 QUESTIONNAIRE PROGICIELS : SÉCURITÉ DES APPLICATIONS TRAITÉES
EXEMPLES :

51 SYNTHÈSE SÉCURITÉ DU SYSTÈME FUTUR EN PHASE D’ÉTUDE PRÉALABLE
EN FIN DE PHASE, ÉTABLIR UNE SYNTHÈSE PERMETTANT DE METTRE EN RELIEF LES RISQUES DETECTES : Risques de manque de maîtrise du processus projet Risques sur le processus produit du système futur Besoins de sécurité du futur projet bilan économique justification des besoins de sécurité

52 La sécurité en Étude Détaillée Fonctionnelle et Technique

53 ACTIONS DE SÉCURITÉ EN PHASE ÉTUDE DÉTAILLÉE FONCTIONNELLE ET TECHNIQUE
Fonctionnel et organisationnel IDENTIFICATION DES PROPRIÉTAIRES D’INFORMATION ET DES GESTIONNAIRES D’HABILITATION. DÉTERMINATION DES MOYENS FONCTIONNELS DE SÉCURITÉ A APPLIQUER : Habilitations SGBD, Sauvegardes, Plan de secours application DÉFINITION DES MOYENS ORGANISATIONNELS DE SECURITE : PROCEDURES DÉGRADÉES : procédures utilisateurs et d’exploitation . Technique informatique DÉTERMINATION DES MOYENS DE SÉCURITÉ INFORMATIQUE A APPLIQUER EN DEVELOPPEMENT : constitution des jeux d’essai, recette DÉTERMINATION DES MOYENS TECHNIQUES DE SÉCURITÉ A METTRE EN ŒUVRE : Habilitations SGBD, Sauvegardes, Plan de secours application IDENTIFICATION DES RISQUES TECHNIQUES : Internet, Intranet, réseau, architecture technique) SYNTHÈSE SÉCURITÉ : Dossier Sécurité Projet « DSP ».

54 Exemple de formalisme : INTÉGRITÉ ET CONFIDENTIALITÉ DES TRANSACTIONS (Flux réseaux)

55 Exemple de formalisme :INTÉGRITÉ ET CONFIDENTIALITÉ DU BATCH (Impressions, traitements par lots)

56 DÉFINITION DES PROCÉDURES DÉGRADÉES
EN REPRENANT LES OBJETS RECENSÉS COMME CRITIQUES, EN TERME DE DISPONIBILITÉ, DÉCRIRE : l’indisponibilité maximum admissible combien de temps peut-on rester sans moyens informatiques, sans que cela devienne insupportable ? combien de temps peut-on travailler avec les mesures dégradées, avant que cela devienne insupportable ? Quelle perte de données est-elle acceptable : 0,5j – 1j – 2j – ou plus ? les mesures et moyens de continuité à prévoir dans le cadre de l’application future utilisateur : procédures organisationnelles, (travail en local sur micro, …) informatique : moyens techniques, (sauvegardes de recours, secours des matériels vitaux, …)

57 DÉFINITION DES PROCÉDURES DÉGRADÉES

58 SÉCURITÉ INFORMATIQUE DES JEUX D ’ESSAI
RECENSER LES DONNÉES EXTRAITES DE FICHIERS D’EXPLOITATION QUI SERVIRONT AUX JEUX D’ESSAI. CLASSER CES DONNÉES EN FONCTION DE LEUR NIVEAU DE CONFIDENTIALITÉ ESTIMÉ. DÉFINIR LES MESURES GARANTISSANT LEUR CONFIDENTIALITÉ masquage des données, visualisation restrictive, modification des données réelles afin de les rendre impersonnelles et non significatives pour un tiers. PRÉCISER LES MOYENS MIS EN OEUVRE POUR ASSURER LA PÉRENNITÉ ET L’ÉVOLUTION COHÉRENTE DES JEUX D’ESSAI.

59 IDENTIFICATION DES RISQUES TECHNIQUES
IDENTIFIER LES RISQUES TECHNIQUES INDUITS PAR DES CHOIX CONCERNANT : Les connexions de l’application avec l’extérieur : Internet, Cloud computing, … Les langages de programmation : Java, Pascal, Cobol, … Les matériels et système d’exploitation : micro portable, Windows 7, Androïde,… L’exploitation centralisée : procédures techniques, etc.

60 SAUVEGARDE ET ARCHIVAGE INFORMATIQUE
PRÉCISER, POUR LES FICHIERS CRITIQUES : LE TYPE DE SAUVEGARDE : Technique : en interne sur site : robot, médiathèque, …(niveau 1), A l ’extérieur : dans un lieu éloigné du centre informatique (niveau 2) Recours : destinées au plan de secours, stockée hors site en prévision d’un back-up (niveau 3), Très Haute Sécurité (THS) : assure l’intégrité des données et applications sauvegardées (niveau 4). LE NOMBRE DE GÉNÉRATIONS, LA PÉRIODICITÉ, ETC.

61 MISE A JOUR DU PLAN DE SECOURS
EN FONCTION DES MESURES DE SÉCURITÉ RETENUES POUR LE PROJET, FAIRE : la mise à jour des actions du plan de secours existant, la création éventuelle d’un plan de secours spécifiques à l’application future en fonction de sa criticité pour l’entreprise.

62 DÉFINITION DE LA SECURITE DES SGBD
DÉFINIR DES MOYENS SPÉCIFIQUES TELS QUE DES AUTORISATIONS PLUS FINES SUR UN CHAMP OU UN ENSEMBLE DE DONNÉES. ASSURER LA RÉPARTITION ET LA SÉPARATION DES DONNÉES SENSIBLES DE FAÇON À EMPÊCHER TOUT ACCÈS NON AUTORISÉ. ASSURER LA SÉCURITÉ SPECIFIQUE DE L’ACCÈS AU SGBD ET ÉVENTUELLEMENT À SA DOCUMENTATION.

63 RECENSEMENT DES MESURES TECHNIQUES DE SÉCURITÉ
METTRE EN PLACE LES COMPLEMENTS DE MESURES TECHNIQUES : Exemple : Sécurité Internet liée à l’application (paramétrage spécifique des firewalls, sondes, scanners,…) Langages de programmation (contrôle qualité de la programmation, …) Matériels et systèmes d’exploitation (habilitations spécifiques, …) Gestion de l’exploitation (automatisation, …) Sauvegarde et archivage, SGBD (granularité des habilitations, …) Plan de secours informatique (actualisation si nécessaire, …)

64 SYNTHÈSE SÉCURITÉ DU SYSTÈME FUTUR EN ÉTUDE DÉTAILLÉE
EN FIN DE PHASE D’ETUDE DETAILLEE, METTRE A JOUR LA SYNTHESE DE FIN D’ETUDE PREALABLE

65 La sécurité dans les phases de construction : réalisation, tests, recette, mise en production, …

66 EXEMPLE du QUESTIONNAIRE : ÉVALUATION SECURITE DE LA PROGRAMMATION ET TESTS

67 EXEMPLE : DE QUALIFICATION SECURITE DU DEVELOPPEMENT INFORMATIQUE

68 EXEMPLE : ÉVALUATION DE LA SECURITE EN PHASE D ’INSTALLATION

69 EXEMPLE : ÉVALUATION DE LA SECURITE LORS DE LA MISE EN ŒUVRE EN PRODUCTION

70 SYNTHÈSE SÉCURITÉ DU SYSTÈME FUTUR
EN FIN DE PROJET, FAIRE UNE REVUE DES POINTS CLES DE SÉCURITÉ MIS EN ŒUVRE

71 Exemple : Cycle de vie projet sécurisé
INITIALISATION CONCEPTION CONSTRUCTION MISE EN OEUVRE Livraison en recette Lancement du projet Fin du projet Comité Comité pilotage Engagements réciproques Comité métier Fin Recette Mise en Service Comité décisionnel Comité investissement Revue d ’Architecture MOE 4 Si choix de progiciel sécurité progiciel à remplir par les fournisseurs Dossier de Spécifications Spécifications organiques Doc produit Cartographie 2 Dossier de Synthèse Dossier d’architecture Analyse des risques métier et informatique Dossier de test V1 Dossier de test V2 3 Mesures proposées 1 8 9 5 7 PV sécurité (bilan) PV sécurité (bilan) Analyse de la criticité Métier, Image Infrastructure, … Liste des exigences Si critique Exigences implémentées 6 Dossier exploitation et sécurité Dossier d’investissement. info Gestion de la sécurité [PDL] Plan de Développement Logiciel Créé Validé 2 Validé 3 Clos REC INT CAD DEV SO SF EBF INS ACC BI OPP I R F [PDP] Plan de projet Note d’opportunité Note de cadrage Plan de formation CDC finalisé Cahier des charges V1 Plan de recette Jeux d’essai Liste des anomalies MOA

72 A BIENTÔT POUR LE’EXAMEN DE CONTROLE