maîtrise des risques dans les projets rené hanouz maîtrise des risques dans les projets rené...

Maîtrise des risques dans les projets Maîtrise des risques dans les projets René HANOUZRené HANOUZ

Maîtrise des risques dans les projets Maîtrise des risques dans les projets René HANOUZRené HANOUZ

RHANOUZ Cabinet d ’expertise en SSI

En introduction quelques mots sur le CLOUD COMPUTINGEn introduction quelques mots sur le CLOUD COMPUTING

CLOUD COMPUTING ou HYPER CONNEXIONCLOUD 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

….

VERS UN MONDE INTERCONNECTE …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 ».

VERS UN MONDE MEDICAL INTERCONNECTEVERS UN MONDE MEDICAL INTERCONNECTE

En Espagne on a crée une plate-forme globale reliant quelques 13000 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.

Version 1.0. - Septembre 2004Diffusion limitée

Formation à la sécurité des projets informatiques

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 SIMalveillances

accès non autorisés au SI, utilisation détournée des règles attaques virales, … fraudes informatiques (le chiffre réel reste caché) …

RETOUR SUR TERRE : CLASSIFICATION DES RISQUESRETOUR SUR TERRE : CLASSIFICATION DES RISQUES



STATISTIQUES Européennes STATISTIQUES Européennes

0

10

20

30

40

50

60

70

80

Accident Erreur Malveillance Internet vecteur

199020002008/9

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



UNE APPLICATION NON SÉCURISÉE 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, …).



LES REFERENTIELS du marchéLES REFERENTIELS du marché

Basés principalement sur le référentiel

INCAS

Basés principalement sur le référentiel

INCAS

Basés sur les référentiels MARION, MEHARI,

ERSICAP…

Basés sur les référentiels MARION, MEHARI,

ERSICAP…

Système Futur

Intégration de la Sécurité dans les

projets et logiciels en construction

Système Existant

Évaluation de la vulnérabilité et des

risques du système déjà construit

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 »

Objectif : SDSSIObjectif : Sécurité des projets et développements



Manque de sécurité : Risques liés au PROCESSUS = démarche de construction du projet

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 ….



Manque de sécurité : Risques liés au PRODUIT = ApplicationManque 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 …



POURQUOI UN PEU DE METHODE : MCPPOURQUOI 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 PROJETLA 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



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

POURQUOI UN PEU DE METHODEPOURQUOI UN PEU DE METHODE



Cycle de vie d’un projetCycle de vie d’un projet

On peut esquisser une comparaison avec notre cycle de vie

Naissance

Mise en exploitation = naissance de l’application

EO

EP

E. Fonct

Real/test

Recette

E. Tech

RodageEnfanceAdolescence

Embryonnaire

Dev.Cérébral

Dif.Organes

Fécondation

Bilans de contrôle

GénéralisationMaturité

MaintenanceVieillesse

Conception d’un nouveau système

Fin de vie

Conceptionenfants

Mise en exploitation



MAITRISE DES RISQUES et MAITRISE DES RISQUES et SECURITE DES PROJETSSECURITE DES PROJETS

MAITRISE DES RISQUES et MAITRISE DES RISQUES et SECURITE DES PROJETSSECURITE DES PROJETS



OBJECTIFSOBJECTIFS

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,…)



OBJECTIFS (suite)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é, …)



EXEMPLES PROJETS ET APPLICATIONSEXEMPLES 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.



EXEMPLES CYBERCRIMINALITEEXEMPLES 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’emails 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



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





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



CHAMPS de la Sécurité ProjetCHAMPS 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)



PRINCIPE de la Maîtrise des risquesPRINCIPE 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 desphases du

projet



LES CRITERES d’analyse du risque sécuritéLES CRITERES d’analyse du risque sécurité

Disponibilité Dn

Intégrité In

Confidentialité Cn

Preuve et contrôle Pn

Réglementation et JuridiqueRn



LA GRADUATION de la gravité des risquesLA GRADUATION de la gravité des risques

StratégiqueStratégique n = 4 (Politique)n = 4 (Politique)

CritiqueCritique n = 3 (mise en cause de la n = 3 (mise en cause de la continuité des activités)continuité des activités)

SensibleSensible n = 2 (perturbation significative)n = 2 (perturbation significative)

INACCEPTABLE

Faible Faible n = 0 ou 1n = 0 ou 1 ACCEPTABLEACCEPTABLE



LES ACTEURS dans un projetLES 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é



ACTIONS SECURITE PAR PHASE PROJETACTIONS 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



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



ACTIONS DE SÉCURITÉ EN PHASE : ÉTUDE D’OPPORTUNITÉ

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



RECENSER LES RISQUES AVERES SUR L’EXISTANTRECENSER 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



MODE D’EMPLOI : IDENTIFICATION DES ACTIVITES CRITIQUES DU PROJET

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



La sécurité en phase d ’É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

ACTIONS DE SÉCURITÉ EN PHASE ÉTUDE PRÉALABLEACTIONS DE SÉCURITÉ EN PHASE ÉTUDE PRÉALABLE



RISQUES LIÉS AU DEVELOPPEMENT DU PROJETRISQUES 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



RISQUES LIÉS A LA TAILLE DU PROJETRISQUES LIÉS A LA TAILLE DU PROJET

1. MATRICE CHARGES / DÉLAIS : Exemple

Délais

Charges

< 3 mois

De 3 à 6 mois

De 6 mois à 1 an

1 an et plus

< 60 JxH

Acceptable

Pas réaliste

Critique

?

+ de 60 à 200 JxH

Pas réaliste

Acceptable

Acceptable

?

+de 200 à 1000 JxH

?

Pas réaliste

Acceptable

Acceptable

> 1000 JxH

?

Critique

Pas réaliste

Acceptable

2. NOMBRE DE DIRECTIONS CONCERNÉES (1, 2, 5 et plus)



CONTEXTE ORGANISATIONNELCONTEXTE 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.



ASPECTS MATÉRIELS

ASPECTS LOGICIELS

CONNAISSANCE INFORMATIQUE DES UTILISATEURS

CONNAISSANCE DU METIER PAR LES UTILISATEURS

CONNAISSANCE DU DOMAINE PAR LES INFORMATICIENS

ENVIRONNEMENT TECHNOLOGIQUE ET SAVOIR ENVIRONNEMENT TECHNOLOGIQUE ET SAVOIR



SYNTHESE DES RISQUES LIÉS AU PROCESSUS PROJETSYNTHESE 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

Faible Sensible Critique

57 110 180 250



Domaines étudiés Projet Note Pondération Note pondération

RISQUES LIES A LA TAILLE DU PROJET1. Importance du développement2. Nombre de directions concernées

56

RISQUES STRUCTURELS1. Impact (%) des fonctions automatisées2. Impact des modifications des procédures3. Impact des modifications de structures4. Appréciation de l’utilisateur5. Participation des fonctions utilisatrices6. Existence d’une équipe de projet utilisateurs / informaticiens

335554

RISQUES TECHNOLOGIQUES1. Aspect hardware (matériel, site nouveaux ou modifiés)2. Aspect software (logiciels nouveaux ou modifiés)3. Connaissance informatique des fonctions utilisatrices4. Degré de connaissance du domaine abordé par les fonctions utilisatrices5. Connaissances du domaine par l’équipe d’informaticiens

35463

Niveau global de risques (TOTAL DES NOTES PONDÉRÉES)

Échelle de notation du niveau de risque

45 110 180 250Faible Sensible Critique Inacceptable

Niveau de risque lié au développement du projet :faiblesensible critiqueinacceptable

EXEMPLE D’OUTIL : MATRICE PONDEREEEXEMPLE D’OUTIL : MATRICE PONDEREE



ANALYSE DES RISQUES DU SYSTÈME FUTURANALYSE 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.



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,

ANALYSE DES RISQUES DU SFANALYSE DES RISQUES DU SF



CLASSIFICATION DICP® pour le flux de données virements

EXEMPLE : FORMALISMEEXEMPLE : FORMALISME

ON OBTIENT AINSI UNE CARTOGRAPHIE DETAILLEE DE LA GRAVITE DES RISQUES SUR LE SYSTEME FUTUR

Gestion des crédits Gestion des crédits

Entreprises et Particuliers

Entreprises et Particuliers

virementsvirements

D2 I3 C1 P2 R1



EXEMPLE : ARCHITECTURE TECHNIQUEEXEMPLE : ARCHITECTURE TECHNIQUE

Serveurs orient

Configuration IBM – site central

ServeursUS

INTERNET

SERVEUR

Bde

B. Données

ETHERNET

UNIXWINDOWS

D3

D2,I 3

C2

IMP

Hardcopy

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

Intranet

D1, I3, P3, C3

C3, P3C2, P2

Firewall / chiffrement

Firewall / chiffrement

PW + carte PW + carte



MESURES DE SÉCURITÉ POUR LE SYSTÈME FUTURMESURES 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).



FAISABILITE ET SUIVI DE MISE EN PLACE DES MESURESFAISABILITE 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, …).



EXEMPLE DE FORMALISMEEXEMPLE 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.

Cotation du risque Type de préjudice Valorisation du risque

C3 = critique Financier, Juridique Perte en gestion de portefeuille : 2,5 Milliards d’Euros

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) Phase de prise en compte Responsable de la mise

en oeuvre Cotation du risque

résiduel Coût des mesures

recommandées Modalités de mise en

place Spécifications

fonctionnelles + Réalisation, Tests, Prod

Informatique +

utilisateurs

C2 = sensible

1 mois x H

Technique et

organisationnelles



ANALYSE DE LA SECURITE DES LOGICIELS OU PROGICIELS RETENUS POUR LE SF

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.



QUESTIONNAIRE SÉCURITÉ DES PROGICIELSQUESTIONNAIRE 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



EXEMPLES

QUESTIONNAIRE PROGICIELS : ADAPTATION A L ’ENVIRONNEMENT

QUESTIONNAIRE PROGICIELS : ADAPTATION A L ’ENVIRONNEMENT

Critères de sécurité Réponse Observations

Le progiciel peut-il bénéficier de la sécurité disponible dans l’environnement logique déjà en place (habilitations non redondantes avec l'existant,…) ?

Le progiciel intègre t-il des fonctions de sécurité liées aux applications interfacées (contrôle de vraisemblance, de validation, de numéricité, …)

La mise en production du logiciel prévoit-elle une recette garantissant le bon fonctionnement des aspects de sécurité ?



QUESTIONNAIRE PROGICIELS : SÉCURITÉ DES PROGICIELS

QUESTIONNAIRE PROGICIELS : SÉCURITÉ DES PROGICIELS

EXEMPLES :


Si à la suite d’un dysfonctionnement, le fournisseur ne peut pas intervenir, le client dispose t-il d’une « procédure logicielle dégradée » pour continuer à travailler ?

En cas de cessation d’activité du fournisseur, le client peut-il accéder à une copie du logiciel source (déposée dans un organisme habilité)?

L’intégrité du logiciel est-elle garantie contractuellement par le fournisseur (ex.: cheval de troie, etc.) avec pénalités ou autres ?



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

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


Le logiciel prévoit-il des solutions de reprise qui permettent en cas d'incident de relancer l'application sans nécessairement reprendre au début (check point restart) ?

Le logiciel est-il livré avec des utilitaires de restauration pour les bases de données ou fichiers spécifiques qu'il met à jour (exemple : oracle financial,…)?

La granularité des droits d’accès aux ressources nécessaires au logiciel (Bases de données, fichier, transaction, etc.) est-elle assurée et paramétrable ?

EXEMPLES :



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é

SYNTHÈSE SÉCURITÉ DU SYSTÈME FUTUR EN PHASE D’ÉTUDE PRÉALABLE

SYNTHÈSE SÉCURITÉ DU SYSTÈME FUTUR EN PHASE D’ÉTUDE PRÉALABLE



La sécurité en Étude DétailléeFonctionnelle et Technique



ACTIONS DE SÉCURITÉ EN PHASE ÉTUDE DÉTAILLÉE FONCTIONNELLE ET TECHNIQUE

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 ».



Fonctions

sensibles de l’application

Ressources : transaction,

écran

Niveau

de risque

Propriétaire ou

fonction autorisée

Mode d’accès

(autorisations liées à la fonction)

Dispositions spécifiques

I C Cré Mod Sup Lec

Virement des

salaires

TP VIRT

3

2

Agents du Service du Personnel

OUI

OUI

NON

OUI

Authentification

forte : carte à puces

Contrôle des virements-

CT VIRT-

3

2

Directeur du

Personnel et auditeurs

NON

NON

OUI

OUI

Idem

Enregistrement des patients : historisue des

maladies

E.MP 3 3 Médecins

infirmières

OUI

NON

OUI

NON

OUI

NON

OUI

OUI

Idem

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

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



Procédures fonctionnelles

Document

Niveau de

risque

Moyens de sécurité préconisés :

Désignation Type Support I C

Fiche de paie Sortie Trt

Papier 3 2 Édition : Imprimante Locale du service du personnel

Diffusion : Porteur

Sauvegarde : Site externe

Archivage : 20 ans sur micro-fiches

Etablissement des salaires Journal des salaires et fiches de paie

Destruction : Broyeur

Édition :

Diffusion :

Sauvegarde :

Archivage :

Destruction :

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

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



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, …)

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



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

Classe de

risque

Indisponibilité maximum admissible

Mesures et moyens de sécurité envisagés pour l’application future

Procédures

Dn Hors

mesures Avec mesures

dégradées

Users.

Info

Description

Etablissement des virements de salaire.

D3

2 jours

15 jours

Oui

Oui

Etablissement de chèques ou virements

sur la base de la paie du mois précédent. Contrat de service engageant

l’informatique sur un dépannage sous 24H maximum.



SÉCURITÉ INFORMATIQUE DES JEUX D ’ESSAISÉ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.



IDENTIFICATION DES RISQUES TECHNIQUESIDENTIFICATION 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.



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.

SAUVEGARDE ET ARCHIVAGE INFORMATIQUESAUVEGARDE ET ARCHIVAGE INFORMATIQUE



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.

MISE A JOUR DU PLAN DE SECOURSMISE A JOUR DU PLAN DE SECOURS



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.

DÉFINITION DE LA SECURITE DES SGBDDÉFINITION DE LA SECURITE DES SGBD



RECENSEMENT DES MESURES TECHNIQUES DE SÉCURITÉ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, …)



SYNTHÈSE SÉCURITÉ DU SYSTÈME FUTUR EN ÉTUDE DÉTAILLÉE

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



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

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



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

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

Aspects de la sécurité à traiter Risque DICP

Sera traité

Observations. Mesures correctives ou raisons du

choix exprimé.

L’auditabilité des programmes sensibles est-elle prévue ?

P Indiquer le dispositif mis en place :

Vérifie-t-on avant mise en production qu’il n’y a plus présence de « code mort » ?

I

Procède-t-on au contrôle et à l’épuration des codes ayant servi pour les tests ? codes abandonnés ? codes à susceptibles d’induire une fraude (chevaux de Troie) ?

I

Les programmes sensibles font-ils l’objet d’une protection particulière (sauvegarde, duplication) ?

DC



EXEMPLE : DE QUALIFICATION SECURITE DU DEVELOPPEMENT INFORMATIQUE

EXEMPLE : DE QUALIFICATION SECURITE DU DEVELOPPEMENT INFORMATIQUE


Sera traité


choix exprimé.

L’environnement applicatif de validation de la sécurité logique est-il conforme aux normes ?

IC Contrôle d’accès à l’application : Habilitations : Sécurité du poste de travail : Application par les utilisateurs :

Les résultats de tests sont-ils matérialisés dans les dossiers de tests ?

I

La recette sur les objets (données, traitements et procédures) critiques, est-elle archivée avec accès protégé ?

CP

Le Procès Verbal de Recette a-t-il été approuvé par les utilisateurs et le responsable sécurité métier ?

DICP



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

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


Sera traité


choix exprimé. Le Manuel Utilisateur comprend-il les consignes de sécurité utiles au bon fonctionnement de l’application ?

DI Habilitations : Sécurité des mots de passe : Incidents de fonctionnement : …

Le Manuel Utilisateur contient-il en particulier : - la description des contrôles utilisateurs ? - les procédures dégradées de reprise Utilisateur

(disponibilité) ?

DI

La convention de Service Informatique/Utilisateurs est-elle validée (signature) en particulier pour les composantes de la sécurité (D, I, C, P) et sa période de révision actée ?

DICP



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

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


Sera traité


choix exprimé. La participation ou la représentation des utilisateurs aux tests de reprise d’activité est-elle prévue et la forme définie ?

D

Les journaux d’exploitation sont-ils archivés pour répondre à des besoins d’auditabilité ?

P

Les Tableaux de Bords Sécurité pour le suivi de l’application en production sont-ils en place ?

DICP

Les procédures de sauvegardes et d’archivage ont-elles été soumises à validation du propriétaire d’information ?

DI



SYNTHÈSE SÉCURITÉ DU SYSTÈME FUTURSYNTHÈSE SÉCURITÉ DU SYSTÈME FUTUR

EN FIN DE PROJET, FAIRE UNE REVUE DES POINTS CLES DE SÉCURITÉ MIS EN ŒUVRE

Fin Recette Mise en Service

MOE

Créé[PDL] Plan de Développement Logiciel

ClosValidé 2

Validé 3

Dossier de Synthèse

Dossier d’architecture

Dossier de test V1

Dossier de test V2

Dossier de Spécifications

Spécifications organiques

Doc produit Cartographie

Exigencesimplémentées

Mesures proposées

MOA

CDC finaliséCahier des charges V1

Note d’opportunité

Note de cadrage

Plan de recette

Jeux d’essai Jeux d’essai

Plan de formation

Liste des anomalies

I R R F[PDP] Plan de projet

Dossier exploitationet sécurité

Dossier d’investissement. info

INITIALISATIONINITIALISATION CONCEPTIONCONCEPTION CONSTRUCTIONCONSTRUCTION MISE EN OEUVREMISE EN OEUVRE

Livraison en recette

Lancement du projet

Fin du projet

ComitéComitéComité pilotage

Comité

Engagementsréciproques

Comité métier

RECINTCAD DEVSOSFEBF INS ACC BIOPP

Comité décisionnelComité investissement

Revue d ’Architecture

Analyse de la criticitéMétier, ImageInfrastructure, …

Gestion de la sécurité

PV sécurité (bilan)

PV sécurité (bilan)

Si choix de progiciel sécurité progiciel à remplir par les fournisseurs

Analyse des risques métier et informatique

Liste des exigences

Exemple : Cycle de vie projet sécurisé

Si critique

1

2

3

4

5

6

78 9



A BIENTÔT POUR LE’EXAMEN DE CONTROLE

maîtrise des risques dans les projets rené hanouz maîtrise des risques dans les projets rené...

Documents