La sécurité informatique - Site de Mohamed Amine … · Wattiau/Akoka 197 5. Politique de sécurité informatique RFC2196 : Une politique de sécurité est une déclaration formelles

196

5. Politique de sécurité informatique

Source : CLUSIF 2010

197Wattiau/Akoka


RFC2196 : Une politique de sécurité est une

déclaration formelles des règles auxquelles

doivent se conformer les personnes recevant

un droit d ’accès au capital technologique et

informatif d ’une entreprise.

Elle doit être mise en œuvre avec :

– la direction de l ’entreprise -> budget et

stratégie,

– le personnel technique -> compétence,

– le personnel juridique -> légalité et recours

198Wattiau/Akoka


La politique de sécurité doit :

– être techniquement possible,

– être compatible avec l ’organisation,

– être imposée au moyen d ’outils ou avec des

sanctions,

– définir les sphères de responsabilités,

– être souple et adaptable en fonction des

changements internes ou externes.

199Wattiau/Akoka


La politique de sécurité doit comprendre :

– la prévention,

– la dissuasion,

– la protection,

– la restauration,

– la compensation.

200Wattiau/Akoka


La politique de sécurité doit :

– être à la mesure des menaces et des enjeux

correspondants,

– adaptée au niveau de vulnérabilité du système

d ’information,

– en rapport avec les ressources dont dispose

l ’entreprise,

– prendre en compte les contraintes du contexte.

201Wattiau/Akoka


Définir une politique de sécurité :

– donner des orientations,

– retenir une stratégie,

– établir des priorités,

– allouer une enveloppe budgétaire,

– mettre en place une structure.

202Wattiau/Akoka


Mettre en place une politique de sécurité :

– analyser la sécurité :

• recenser les menaces,

• analyser les risques,

• apprécier le niveau de vulnérabilité du SI,

• estimer les conséquences et les enjeux majeurs,

• exprimer les besoins en services de sécurité

– étudier une solution :

• rechercher les outils physiques et logiques,

• établir les procédures, standards et consignes,

• évaluer les coûts des ressources nécessaires

203Wattiau/Akoka


– Mettre en place une solution :

• installer et tester les outils,

• valider les procédures,

– Exploiter et maintenir la solution :

• animer la structure,

• veiller au respect des consignes,

• tester régulièrement la robustesse des dispositifs,

• suivre l ’évolution des versions d ’outils,

• effectuer régulièrement un bilan.

204Wattiau/Akoka

5.1. Mise en place d’une

politique de sécuritéLe réseau d ’entreprise peut être divisé en

trois composants distincts :

– l ’infrastructure principale interne,

– la connectivité d ’accès distant :

• services RTC ou RNIS

– la connectivité Internet :

• fournisseur de service (ISP-Internet Service

Provider)

Ces 3 composants ont des besoins différents

mais doivent être cohérents

205Wattiau/Akoka

5.2. Eléments d’une architecture

de sécurité Identité

– authentification : mots de passe

– autorisation : partitionnement du réseau

Intégrité :

– sécurité physique

– sécurité logique d ’accès

– sécurité de périphérie : pare-feu

Confidentialité

– classifier les données et, le cas échéant, crypter

206Wattiau/Akoka

5.2. Eléments d’une architecture

de sécuritéDisponibilité

– sécurité physique

– sécurité logique

Audit

– vérifier et surveiller la politique de sécurité

– à intervalles réguliers

– journal d ’audit

207Wattiau/Akoka

5.3. La spirale de la sécurité

L ’entreprise

Des mesures

de sécurité

L ’environnement

hostile

Met

en place

D ’après J. Gonik - Management de la sécurité des systèmes d ’information

208Wattiau/Akoka

5.4. Les facettes de la sécurité

S.I.

Nature :

physique

logique

organisationnelle

Mesures :

prévention

dissuasion

protection

restauration

compensation Impact souhaité

en matière de :

disponibilité

intégrité

confidentialité

Champ d ’application :

SI existant

SI en développement

SI futur

Approche par :

environnement hostile

vulnérabilité des systèmes

moyens de sécurité existants

Mise en oeuvre :

systématique ou

après analyse du risque

Adapté de J. Gonik - Management de la sécurité des systèmes d ’information

209Wattiau/Akoka

5.5. Les approches de la sécurité

Par l’analyse du risque :

– conséquences si accident, erreur, malveillance

Par l’appréciation des vulnérabilités :

– recherche des points faibles dans la protection

du SI

Par la mise en place de moyens

210Wattiau/Akoka

5.5. L’évaluation des risques

Identification des ressources :

– matériels, logiciels, données, personnes,

documentations

Valeur des ressources

– processus très objectif pour les matériels,

logiciels

– en termes d ’importance ou de gravité pour les

autres

J. Akoka211


Vulnérabilité: faiblesse du SI

Menace: ce qu’on craint

Enjeux: ce qu’on veut protéger

Risque: danger + ou – probable émanant

d’une menace et résultant d’une

vulnérabilité et affectant des enjeux

Risque= Enjeux*Vulnérabilité*Menace

J. Akoka212


Aspects réglementaires

Perte de performance métier

Réputation

Perte de confidentialité des données personnelles

Mise en danger du personnel

Non respect de la loi

Pertes financières

Arrêt de l’activité

J. Akoka213

5.5. Stratégies de gestion des risques

Identifier les risques

Accepter les risques

Réduire les risques

Transférer les risques

Rejeter le risque

J. Akoka214

5.5. Réduire la potentialité du risque

Mesures structurelles

– Localisation, architecture, organisation

Mesures dissuasives

– Identification, journalisation, sanctions

Mesures préventives

– Contôles d’accès, détection, interception

J. Akoka215

5.5. Réduire l’impact du risque

Mesures de protection

– Détection, intervention, non propagation

Mesures palliatives

– Restauration, reconfiguration, secours

Mesures de récupération

– Assurances, actions en justice

216Wattiau/Akoka

5.6. Un modèle de la sécurité

[Gonik]

Menace Fait naître un Risque

Se concrétise en

Agression

Peut provoquer une

Atteinte Se traduit par un Impact

Exprime la probabilité

d ’apparition d ’une

Exprime le

niveau d ’un

217Wattiau/Akoka

5.7. Matrice d’aversion aux

risques

POTENTIALITE IMPACT

Extrêmement grave

Très grave

Moyennement grave

Peu grave

Forte Moyenne Faible Insignifiante

1

2

1

2

1

1

2

2

1

1

4

4

3

4

3

3

Risque = probabilité de la menace * perte attendue

218Wattiau/Akoka

5.8. La méthode EBIOSEtude du

contexte

Expression

des besoins

de sécurité

Etude des

menaces

Identification

des objectifs

de sécurité

Détermination

des exigences

de sécurité

219Wattiau/Akoka

5.8. La méthode EBIOS

Etude du

contexte

220Wattiau/Akoka


Expression

des besoins

de sécurité

221Wattiau/Akoka


Etude

des

menaces

222Wattiau/Akoka


Identification

des objectifs

de sécurité

223Wattiau/Akoka


Détermination

des exigences

de sécurité

224Wattiau/Akoka

5.9. La méthode MEHARI CLUSIF : Club de la Sécurité des Systèmes d’Information

Français

MEthode Harmonisée d'Analyse de RIsques

analyse et évaluation quantitative des facteurs de risque propres à chaque situation,

Analyse des vulnérabilités (MARION)

définir une politique de maintien des risques à un niveau convenu.

L'appréciation des risques dépend de la vision de la Direction Générale face à ses objectifs "business"

la présence (ou l'absence) de mesures de sécurité va réduire (ou non), soit la potentialité de survenance d'un sinistre, soit son impact.

L'interaction de ces types de mesures concourt à réduire la gravité du risque jusqu'au niveau choisi.

Un outil : RISICARE

225Wattiau/Akoka

Synoptique des mesures de sécurité

selon MEHARI

226Wattiau/Akoka

MEHARI : plan stratégique de

sécurité

Métrique des risques

et objectifs de sécurité

Valeurs de l’entreprise :

Classification des

ressources

Politique de sécuritéCharte de

management

PLAN STRATEGIQUE DE SECURITE

227Wattiau/Akoka

MEHARI : plan opérationnel de

sécurité

Préliminaire : domaine couvert,

base de scenarii, décomposition cellulaire

Evaluation de

la gravité des

scenarii

Audit

de l’existant

Expression des besoins

de sécurité

PLAN OPERATIONNEL DE SECURITE

228Wattiau/Akoka

MEHARI : plan opérationnel

d’entreprise

Elaboration

d’un tableau

de bord

de la sécurité

Choix

d’indicateurs

représentatifs

Rééquilibrage

et arbitrage

entre unités

PLAN OPERATIONNEL D’ENTREPRISE

Tableau de bord – quelques indicateurs

Nombre d’incidents sur une période

Conformité avec les normes

Conformité avec la politique de sécurité

Vulnérabilités détectées

Nb d’attaques arrêtées par les dispositifs de sécurité

Impacts directs et indirects des incidents

Taux de mise à jour des signatures antivirales

Evaluation des risques métier

Suivi du budget consacré à la sécurité

Taux de mise à jour des patchs de sécurité

Avancement des projets de sécurisation

Taux de personnes sensibilisées229Wattiau/Akoka

230Wattiau/Akoka

5.9.1. La méthode MARION

Histoire :

– introduite en France en 1984

– conçue et développée par le CLUSIF, Club de

la Sécurité des Systèmes d ’Information

– Méthode d ’Analyse des Risques Informatiques

Optimisés par Niveau

– utilisée en Europe occidentale et au Québec

– par les banques, assurances, groupes industriels,

PME.

231Wattiau/Akoka


6 principes de base

– 1. la sécurité implique une forte implication de

l ’entreprise à tous les niveaux

– 2. MARION vise à réduire les vulnérabilités en

mettant en place des moyens de sécurité

cohérents et adaptés aux enjeux

– 3. il n ’y pas de relation simple et générale du

type risque-solution

232Wattiau/Akoka


6 principes de base (suite)

– 4. il faut distinguer risques maximaux et risques

moyens

• les risques maximaux mettent en cause la survie de

l ’entreprise -> scénarios, enjeux et ripostes

• les risques moyens -> raisonnement statistique sur la

base des sinistres observés, puis audit quantitatif et

pondéré

233Wattiau/Akoka


6 principes de base (suite)

– 5. le choix des moyens de sécurité est fondé sur :

• la priorité des moyens de protection (blocage des grands

risques) par rapport aux moyens de prévention

(réduction de la fréquence des risques),

• l ’équilibrage des moyens de prévention et de

protection,

• la réduction des incohérences et des failles,

• l ’optimisation du rapport qualité-coût des moyens de

sécurité.

– 6. Le schéma directeur de la sécurité informatique

doit être exhaustif.

234Wattiau/Akoka


Intérêts

– méthode d ’audit :

• donne un avis sur le niveau de sécurité existant

– évalue les risques potentiels, incluant :

• l ’informatique,

• et l ’ensemble des facteurs qui contribuent à la

sécurité

– quantifie les enjeux financiers

– débouche sur un plan d ’action

235Wattiau/Akoka


Classe la sécurité selon 5 thèmes :

– environnement organisationnel et économique,

– sécurité physique,

– sécurité informatique générale,

– sécurité de l ’exploitation,

– sécurité des applications.

Ces 5 thèmes sont subdivisés en 27 facteurs,

(puis en 105 points), coordonnées polaires

de la rosace de sécurité.

236Wattiau/Akoka


Les différentes versions de la méthode

– L’ensemble méthodologique MARION,

développé par le CLUSIF est décomposé en

trois méthodes :

• MARION-AP (méthodologie et analyse des risques

informatiques) s’applique dans le cas d’un site

unique ou d’une collection de sites très semblables

• MARION-MICRO (micro-informatique)

• MARION-PMS/PME (sécurité des petits et moyens

systèmes informatiques)

237Wattiau/Akoka


Analyse des risques

Analyse de la sécurité

existante

Risques maximum

admissibles

Evaluation

des contraintesChoix des moyens

Plan d’orientationPlan de sécurité

informatique

238Wattiau/Akoka


Les étapes de MARION-AP

1.les préliminaires à la mise en oeuvre :

sensibilisation de la direction

• Il est souhaitable de sensibiliser la direction générale

par un exposé bâti sur le modèle suivant :

– Exemples concrets de sinistres réels qui sont survenus

récemment

– Commentaires sur les statistiques et l’évolution des risques

informatiques

239Wattiau/Akoka

5.9.1. La méthode MARIONLes étapes de MARION-AP

1. les préliminaires à la mise en oeuvre : le CAM

• On constituera ensuite un “Comité d’Application de la

Méthode” (CAM) regroupant de manière classique les

fonctions suivantes :

– Direction informatique

– Organisation, études, exploitation, etc…

– Sécurité générale

– Audit interne

– Responsable assurances, risk-management

– Direction financière, contrôle de gestion

– Principaux utilisateurs, correspondants informatiques

– Un conseil extérieur (éventuellement)

240Wattiau/Akoka

5.9.1. La méthode MARION2. Analyse des risques

• Cette étape permet de déterminer exhaustivement

et quantitativement, les risques courus par

l’établissement et dus à l’informatique

• Il convient de définir la typologie, la hiérarchie et

les montants maximaux de ces risques

• Cette étape est délicate et longue :– elle consomme en moyenne 40% de la durée d’application

de la méthode

241Wattiau/Akoka


• Sélection des fonctions stratégiques

– applications pouvant mettre en jeu la pérennité d’une

activité ou l’image de la société

• Recensement des scenarii de risques pour chaque

fonction retenue

– deux types de risques :

• les sinistres prenant naissance au sein même de la

structure informatique (accidents matériels,

interruptions d’activité ; vol, sabotage…)

• les sinistres spécifiques aux fonctions concernées par

les applications retenues (erreurs de saisie,

d’utilisation, fraudes, sabotage, destruction, vol…)

242Wattiau/Akoka


• Evaluation du coût maximum de pertes engendrées par

chaque scénario

– Cette évaluation repose sur des interviews de différents

responsables de la structure informatique et des fonctions

“utilisateurs” concernée par les applications stratégiques.

• Conséquence des dégâts matériels et annexes

(régénération des sauvegardes : mise en oeuvre des

moyens de secours…)

• Evaluation de l'indisponibilité (temps mort, mode

dégradé…)

• Conséquences sur les fonctions utilisatrices ? (internes

ou externes)

• Hiérarchisation des sinistres potentiels recensés

243Wattiau/Akoka


3. Expression du risque maximum admissible

• Il est fixé par la Direction et correspond au “seuil

critique”

• Il représente la perte maximale générée par un

sinistre informatique, que la société peut accepter

• La détermination de ce seuil dépend essentiellement

de facteurs non calculables liés aux objectifs fixés

par la Direction

244Wattiau/Akoka

5.9.1. La méthode MARION4. Analyse de la sécurité existante - MARION CC

• audit de survol

• plus de 500 questions qui analysent la qualité et la

cohérence des 27 facteurs caractéristiques de la

sécurité : chaque réponse est une note entre 0 (non) et

4 (oui)

• chaque facteur est pondéré : la pondération est

proportionnelle à l ’espérance mathématique des

sinistres induits par chaque facteur

• la rosace de MARION permet de visualiser :

– les incohérences,

– les points faibles et leurs incidences relatives.

245Wattiau/Akoka


4. Analyse de la sécurité existante - MARION CC

• la structuration de l ’étape la rend très légère : 10% de

la durée totale

• répondent au questionnaire :

– les membres du comité,

– les personnes extérieures au comité pour certaines parties

spécifiques

• séances plénières de validation et de consolidation

246Wattiau/Akoka


5. Evaluation des contraintes (5% de l ’effort total)

• inventorier les différentes contraintes

• calculer la répartition optimale du budget à allouer à la

prévention et à la protection pour minimiser le coût des

sinistres

• recenser les paramètres limitant le champ des

orientations réalisables :

– contraintes techniques : situation géographique, type de

matériel, etc.

– contraintes humaines : relations du travail, règles de

fonctionnement,

– contraintes financières

247Wattiau/Akoka

5.9.1 La méthode MARION

6. Choix des moyens (10% avec l ’aide d ’un logiciel)

• en protection : pour réduire les risques maximum en

dessous du seuil critique : porter à la note 3 les facteurs

de protection :

– contrôles permanents

– sécurité spécifique incendie

– systèmes et procédures de secours

– sauvegarde

• en prévention : classer les facteurs selon la note obtenue :

– traiter d ’abord les facteurs dont la note est 0,

– puis ceux dont la note est 1, etc.

– évaluer, chaque fois, le budget nécessaire

248Wattiau/Akoka


7. Orientation et avant-projet

• propositions d ’amélioration

• dans l ’ordre de priorité de l ’étape 6 (choix des

moyens),

• rédiger un plan de sécurité informatique

249Wattiau/Akoka


Appréciation générale de la sécurité :

N°

facteur

Libellé Pondé-

ration

Nb de

questions

Exemple de

question

101 Organi-

sation

générale

30 28 Existe-t-il un

responsable de la

sécurité générale ?

102 Contrôles

perma-

nents

50 13 Existe-t-il un

correspondant

informatique dans

chaque fonction de

l’entreprise ?

103 Réglemen

tation et

audit

45 14 Le service d’audit

interne dépend-il

directement de la

direction

générale ?

250Wattiau/Akoka


Les facteurs socio-économiques

– un seul facteur n° 201

– poids : 10

– 11 questions

– La marge brute des trois dernières années a-t-

elle augmenté par rapport à celle des trois

années précédentes ?

251Wattiau/Akoka


Les principes généraux de la sécurité ( 11

facteurs, 266 questions, poids total : 320)

301 Environnement

de base

40 38 Le bâtiment abritant les

locaux informatiques est-il

protégé contre la foudre ?

302 Contrôle

d’accès

physique

35 41 Pour les salles

informatiques, y a-t-il une

trace écrite systématique

identifiant chaque accès ?

…

310 Personnel

informatique

30 21 Le règlement intérieur a-t-

il été adapté aux

spécificités de

l’informatique (horaires

spéciaux, avantages

divers) ?

252Wattiau/Akoka


La sécurité logique et des réseaux :

253Wattiau/Akoka


La sécurité de l ’exploitation (5 facteurs,

115 questions, poids total 180)

501 Archivage

désarchivage

10 13 Les locaux d’archivage

sont-ils protégés par un

système de contrôle

d’accès ?

502 Saisie et

transfert de

données

10 9 Existe-t-il des procédures

vérifiant que toute

l’information à saisir a

bien été saisie et

enregistrée ?

…

254Wattiau/Akoka


La sécurité des études et réalisations

601 Procédures de

recette

50 27 Existe-t-il des procédures de

recette appliquées

systématiquement avant la mise

en exploitation pour toute

application ?

602 Méthodes

d’analyse

programmation

50 26 Y-a-t-il un planning

systématique concernant tous

les projets en développement ?

603 Contrôles

programmés

90 29 Y-a t-il périodiquement envoi

de données parasite pour piéger

d’éventuelles falsifications de

contrôles dans les programmes

stratégiques ?

604 Sécurité des

progiciels

20 8 Le choix des progiciels repose-t-

il sur la capacité des SSII à

maintenir et à faire évoluer les

produits

255Wattiau/Akoka


Réponses aux questions :

– 3 = bon niveau suffisant de sécurité

– si la réponse à une question est clairement oui

ou non, la réponse est cotée 4 ou 0

– si l ’on peut moduler, on utilisera les notes

intermédiaires 1, 2 , 3 traduisant un niveau de

sécurité devenant de plus en plus satisfaisant

– si une question est sans objet, la réponse est 3

256Wattiau/Akoka

Un exemple de

rosace MARION

257Wattiau/Akoka

5.10. Les autres méthodes

INCAS : – INtégration dans la Conception des Applications de la

Sécurité : méthodologie de développement d ’applications

sécurisées -> CLUSIF

MELISA : – méthode d ’analyse de vulnérabilités mise au point par la

DGA puis reprise par une SSII

CRAMM : – méthode d ’analyse de la sécurité imposée par le

gouvernement britannique

OCTAVE :

– Proposée par Carnegie Mellon

258Wattiau/Akoka

5.10. Comparatif des méthodes

Années 1990 : méthodes de détection des vulnérabilités -> Marion, Melisa, etc.

– Principalement pour systèmes centraux

– Et pour les grandes entreprises

Années 2000 : méthodes de gestion des risques (actifs informationnels, etc.) -> Mehari, Octave, CRAMM, EBIOS

Au-delà : méthodes dédiées par secteur d’activité ?

J. Akoka259

5.10. Comparatif des méthodes

Analyse des risques : EBIOS, OCTAVE, MEHARI, MARION

Processus : SSE-CMM / ISO 21827, CobIT

“Best practices” : BS7799 / ISO 17799,-ISO27001, ITBPM, ITIL, RFC 2196

Produit : Critères Communs / ISO 15408, ITSEC

Guides informationnels : NIST 800-30, ISO 13335, PSSI, TDBSSI

Multiples : CRAMM

Utilisation des méthodes (Clusif

2010)

Seulement 38% des entreprises utilisent une

méthode formelle

15% réalisent une analyse de risques

exhaustive à l’aide d’une méthode formelle260Wattiau/Akoka

261

5.11. Plan de continuité d’activité (PCA)

Couverture du PCA

262Wattiau/Akoka

PCA, PRA, PCI, PSI

Plan de continuité, de reprise d’activité

Plan de continuité informatique, plan de

secours informatique

263Wattiau/Akoka

PCA

PRA

PCI

PSI

264

Définition

PCA :

– mode planifié et formalisé de réactions aux sinistres en

vue de diminuer leurs impacts sur l’activité de

l’entreprise.

Composants d’un PCA :

– un plan de secours informatique (PSI)

– un plan de gestion des crises

– un plan de reprise d’activité (PRA)

– un plan de continuité opérationnelle (PCO)

– des procédures de fonctionnement dégradé

265

Démarche d’élaboration d’un

PCA

Étape 1 : Diagnostic et définition des

besoins

Étape 2 : Élaboration d’une stratégie de

continuité

Étape 3 : Test et maintenance du PCA

266

Étape 1 - Diagnostic et définition

des besoins

1- Identifier les processus vitaux de la société : état des lieux sécuritaire, organisationnel, logistique, et technologique

2- Déceler les menaces sur les hommes, les infrastructures, le système d’information, les équipements et les locaux

3- Évaluer l’impact d’une interruption d’activité sur la pérennité de l’institution

4- Établir une typologie des sinistres

267

Analyse d’impact

Analyser le fonctionnement de l‘entreprise

identifier les processus permettant à l‘entreprise de fonctionner

identifier les ressources liées à ces processus

Pour chaque menace identifiée

définir des seuils de tolérance (par processus)

définir l‘impact financier, humain, légal en cas de matérialisation

Définition des durées d‘indisponibilité maximales durée maximale d‘une interruption pour chaque processus identifié

durée d‘interruption par élément du système lié aux processus

formalisation des objectifs définis

Cette analyse n‘est efficace que si tous les acteurs du SI sont impliqués : collaborateurs, spécialistes, managers.

268

Étape 2 - Élaboration d’une stratégie de

continuité

1- Proposer des solutions de reprise pour parer à l’ensemble des scénarios de sinistres

2- Modéliser une organisation de crise

3- Rédiger et assister les métiers à la rédaction des procédures fonctionnelles et opérationnelles

4- Sensibiliser les opérationnels aux enjeux et procédures du PCA

5- Harmoniser les procédures techniques avec l’organisation de crise

6- Développer une communication de crise efficace et rapide

269

Étape 3 - Test et maintenance du PCA

1- Contrôler la fiabilité des travaux, tester et homologuer la solution de secours proposée.

2- Mettre en place un PCA opérationnel répondant à l’expression des besoins de continuité par activité

3- Définir les principes organisationnels du maintien opérationnel du PCA et de ses composantes fondamentales

Plan de sauvegarde informatique

Plan de gestion de crise

Plan de reprise des moyens techniques et des activités métiers

Plan de retour à la normale

270

Exemple n°1 – L’existant L’entreprise

– Un groupe de protection sociale français, avec plusieurs métiers (retraite, prévoyance, gestion d’actifs, épargne retraite,…)

– Un siège centralisé et plusieurs sites de gestion

– Des activités essentiellement fondées sur des applicatifs métiers

– Le PCA :

• obligation imposée par le Groupe

• fortement conseillé dans le cadre de la réglementation

La situation

– Un plan de continuité d’activité existe depuis plus de 3 ans

– L’organisation des sites de gestion a fortement évolué : le PCA n’est plus à jour

– PCA global : ne prend pas en compte les spécificités des sites ainsi que les différents processus

– Lors d’un incident récent, il n’a pas été utilisé : l’applicatif métier permettant de réaliser le processus de suivi allocataire n’a pas été disponible pendant une journée avec des conséquences importantes :

• Inactivité de 120 salariés

• Arrêt du traitement des prestations clients

• Accroissement du stock des dossiers en attente

271

Exemple 1: L’action

Le besoin : permettre le déclenchement de la cellule de gestion de crise au bon moment et la mise en place de procédures adaptées– Diagnostic du PCA existant

– Analyse des processus

– Élaboration d’actions d’amélioration

Diagnostic– PCA global correctement construit sur les trois scénarios « classiques »

– Obsolescence du contenu par rapport à l’évolution des activités sur les différents sites

– Peu ou pas de maîtrise du PCA par les responsables opérationnels

– Contenu en décalage par rapport à des arrêts d’activités locaux

Propositions de mise en œuvre– Analyse des processus critiques et analyse locale des risques

– Adaptation locale de l’organisation de gestion de crise et de continuité d’activité et des procédures associées

– Formation des responsables opérationnels

– Réalisation de tests

Le résultat

– PCA opérationnel

– Continuité d’activité adaptée aux conséquences des arrêts

– Sensibilisation et pilotage accrus

272

Les points clés de cette étude

Détermination du temps d’interruption maximal

Hiérarchisation des processus

Définition des processus critiques

273

Exemple n°2 : L’existant

L’entreprise– Société de services aéroportuaires, 500 collaborateurs

– Un siège centralisé en Île-de-France

– Des agences de petite taille disséminées à l’international

– Une forte rotation des personnels

– PCA : obligation imposée par ses partenaires (compagnies aériennes, aéroports, etc.)

La situation– Un PCA existe depuis plus de 10 ans

– Il est à jour et testé sur les technologies de l’époque mais n’est pas à jour

• sur les technologies plus récentes

• pour les personnels nouveaux, dont les formations opérationnelles sont prioritaires

– Lors d’un incident récent, il n’a pas été utilisé :

• l’incident a été géré par un chef de centre en autonomie et a eu des répercussions fortes :

– Insatisfaction et retards clients avec pénalité

– Envois de deux équipes pendant 5 jours pour intervention d’urgence

274

Cas 2 : L’action

Le besoin– Diagnostic du PCA existant

• Risques couverts et efficacité

• Système documentaire et outillage

– Élaboration d’actions d’amélioration

– Objectif : trouver des solutions progressives et limitées en ressources

Diagnostic– Bonne structuration des équipes et des documents

– Obsolescence du contenu sur tout ce qui est récent

Propositions de mise en œuvre– Imposer la formation à l’embauche et l’intégration immédiate des nouvelles

technologies

– Renforcer les compétences et outils de gestion des risques dans le processus qualité

– « Reporting » semestriel avec indicateurs sur le taux de couverture et de personnes formées

Le résultat– Pérennisation de l’investissement du PCA initial

– Sensibilisation plus fréquente au domaine de la continuité d’activité

– Pilotage fort et mature du domaine

275

Points Clés de cette étude

Un PCA repose sur une organisation :

en maintenir l’efficacité est une démarche d’amélioration continue

Maintien en conditions opérationnelles de l’existant

Documents et procédures opérationnelles (Responsables PCA opérationnels)

Dispositifs disponibles et de qualité suffisante (Équipes techniques (métiers, DSI, moyens généraux))

Personnel formé et entraîné (Équipes techniques (métiers, DSI, moyens généraux))

Évolutions technologiques ou organisationnelles

Intégration des nouveaux projets (Responsable PCA Métiers)

Intégration des réorganisations (Responsable PCA Métiers)

Évolution de l’environnement

Veille et analyse de risque (« Risk manager »)

Prise en compte des nouveaux besoins (Responsable PCA Métiers)

276

Exemple 3 : l’existant

L’entreprise

– Société de conditionnement, 100 collaborateurs

– Un siège centralisé

– Différents sites disséminés dans la région concernée

– Des exigences contractuelles fortes en termes de délai vis-à-vis des clients

La situation

– Un PCA existe depuis 4 ans. Investissement lourd.

– Il est à jour et prend en compte l’interruption totale ou partielle des chaînes de conditionnement.

– Une tempête a dévasté le département. Le site a été épargné et est resté opérationnel.

– Pourtant, l’activité de l’usine a été perturbée pendant un certain temps : l’état des routes et les dégâts sur les habitations ont empêché les salariés de travailler.

– Les conséquences ont été importantes entraînant des insatisfactions et retards clients avec pénalités

277

Cas 3: l’action Le besoin

– Diagnostic du PCA existant

– Définition d’axes d’amélioration

– Objectif : atteindre une couverture efficiente des risques liés à l’interruption d’activité

Diagnostic

– PCA complet en termes de :

• Identification des risques

• Proposition de solutions techniques

• Non prise en compte de la gestion du personnel

Propositions

– Implication de la Direction Ressources Humaines dans la démarche PCA

– Intégration de la dimension RH dans les stratégies de continuité définies

Les résultats

– Opérationnalité du PCA

– Sensibilisation accrue du personnel au domaine de la continuité d’activité

278

Le PCA - Dispositions Techniques et

Architecturales

Elles couvrent l'ensemble des moyens techniques à déployer en amont.

Selon la typologie du plan de continuité, son périmètre couvrira :

– Les salles aussi bien que les biens d'équipements,

– Les données disponibles et intègres sur les systèmes

– Les applications et systèmes pré installés et pré configurés sur l'environnement de secours,

– Des réseaux de données disponibles,

– Des réseaux téléphoniques disponibles,

– Une architecture de sauvegarde sur le site distant.

Le PCA - Dispositions Procédurales

Objectif : permettre à l'organisation de formaliser les

dispositions opérationnelles à réaliser une fois la

survenance du sinistre.

Les procédures et processus doivent être formalisés,

diffusés, compris et maîtrisés.

La documentation doit rassembler tous les éléments

nécessaires à l'exécution du PCA :

des procédures de restauration et de sauvegarde,

des documents fonctionnels tels que la remise en service des

applications métiers,

des documents décrivant les membres de la cellule de crise,

liste des numéros des numéros de téléphones des spécialistes,

des fournisseurs, des mainteneurs, éditeurs, etc.

279

Dispositions Procédurales

Les procédures d'intervention décrivent le mode de bascule opérationnel. Elles doivent inclure :

– Les rôles et responsabilités,

– Les modes opératoires,

– Les formulaires types,

– Les instructions de travail,

– Les procédures de soutien, de communication, durant la crise,

– etc.

280

281

Dispositions Organisationnelles

Elles prévoient l'organisation qui sera mise en place durant la crise

Elles doivent être exhaustives et conformes notamment au code du travail

Habilitation

– Les personnes habilitées doivent être identifiées en amont de la crise

Formation

– Sensibiliser le personnel sur les enjeux du PCA, et former les équipes qui assureront la reprise.


Cellule de crise constituée de:

– manager, y compris de la direction,

– la direction technique,

– logistique, etc.

Dispositions concernant la communication vers l'extérieur, afin d'assurer un relais vers les parties prenantes, clients, actionnaires, presses, etc.

282


Contrats de travail – Peut amener à modifier momentanément la

durée légale de travail des collaborateurs

– Se prémunir juridiquement de cet écart dans les contrats de travail

La cellule de crise doit être suffisamment "staffée" pour permettre l'exécution du plan de reprise, et de retour à la normale

283

284

Les constats fréquents

Les PCA les plus détaillés ne sont pas les plus efficaces

Certains sont périmés (technique, procédures)

Certains sont indisponibles

Certains sont focalisés sur les systèmes informatiques

Manques de tests

Sous-estimation du facteur stress/émotionnel

Personnes clés du PCA toutes au même endroit

Équipes de secours pas incluses dans les listes d’appel

Facteurs clés de succès d’un PCA

285

Avoir préparé le projet à temps

Avoir un responsable bien positionné dans la structure

Avoir bien évalué risques et impacts

Avoir une stratégie de couverture claire

Maintenir un site de secours en cohérence avec les besoins

Avoir écrit les procédures nécessaires avec le bon niveau de détail

Vérifier régulièrement le plan de secours (tests, formation, maintenance)

Le RSSI

Missions :

– Définition et évolution des exigences de

sécurité

– Définition et mise en œuvre des solutions

opérationnelles et techniques

– Exploitation au quotidien et réaction sur

incident.

– Contrôle, suivi et audit de la bonne application

des mesures de sécurité.

– Sensibilisation et formation permanentes à la

problématique sécuritaire, auprès des différents

intervenants dans les systèmes d’information 286Wattiau/Akoka

5.12. Le RSSI

Rattachement hiérarchique :

– A la direction générale s’il est en charge du

management des risques en général

– A la Direction des Systèmes d’Information, s’il

a en charge :

• L’initialisation

• La coordination

• La cohésion des politiques des systèmes

d’information

287Wattiau/Akoka

Le spécialiste sécurité

288Wattiau/Akoka

289Wattiau/Akoka

5.13. Les certifications

Certification des logiciels et des matériels

– Instance officielle : DCSSI Direction Centrale de la Sécurité des Systèmes d’Information, organisme inter-ministériel, dépend du 1er

ministre

– Sociétés privées : CESTI (Centre d’Evaluation de la Sécurité des Technologies de l’Information), instruisent les dossiers pour la DCSSI qui certifie

– 6 niveaux de certification ITSEC (Information Technology Security Evaluation Criteria) -> Europe

– 7 niveaux pour la certification Critères Communs (assurance de l'évaluation)

• EAL1 : testé fonctionnellement

• EAL2 : testé structurellement

• EAL3 : testé et vérifié méthodiquement

• EAL4 : conçu, testé et vérifié méthodiquement,

• EAL5 : conçu de façon semi-formelle et testé

• EAL6 : conception vérifiée de façon semi-formelle et testé

• EAL7 : conception vérifiée de façon formelle et testé.

ISO17799

290Wattiau/Akoka

291Wattiau/Akoka

5.11. Les certifications ISO17799

– Issue de la norme anglaise BS7799-1

– Guide de bonnes pratiques (une centaine de recommandations, majoritairement d’ordre organisationnel)

ISO21827– Modèle de maturité de l’ingénierie de la sécurité

– SSE-CMM Systems Security Engineering – Capability Maturity Model : 5 niveaux (effectué de façon informelle, planifié et suivi, bien défini, quantitativement contrôlé, amélioration continue)

ISO15408– Critères communs

– Cibles : matériels réseaux, SGBD, IDS (Intrusion Detection Systems, OS, VPN, composants d’infrastructures

292Wattiau/Akoka

5.11. Les certifications

ISO se définit comme un système de management

ISO 17799 (BS7799) est devenu un standard de facto

ISO 27000 amène les standards à un niveau supérieur

Beaucoup d’organisations l’utilisent

La plupart sont sur la voie pour le mettre en place

ISO27000 insiste sur la mesure de la sécurité, pour – Évaluer les améliorations

– Montrer son adéquation aux standards, contrats, SLA, etc.

– Justifier des dépenses futures

– Obtenir une certification

– Identifier l’efficacité de certaines mesures de sécurité

– Obtenir la confiance du management

293Wattiau/Akoka

ISO27002

294Wattiau/Akoka

6. Conclusion - Les freins à une réelle

efficacité de la sécurité des SI

faible prise de conscience des utilisateurs 51%

rythme des évolutions informatiques 50%

limites ou contraintes budgétaires 48%

absence d'un processus formel de gestion de la sécurité des SI 45%

engagement/sensibilisation insuffisant ou inexistant des cadres dirigeants 42%

manque de temps pour planifier ou mettre en œuvre des solutions à long terme 42%

communication inefficace avec les utilisateurs 40%

problème de cohérence entre les besoins en sécurité des SI et les objectifs métier 37%

difficulté à justifier l'importance de la sécurité des SI 35%

disponibilité / fidélisation d'un personnel compétent 34%

architecture de sécurité des SI existante 28%

incertitude de la conjoncture économique 22%

mauvaise relation avec le fournisseur d'un produit ou d'un service de sécurité 16%

technologie de sécurité des SI inefficace ou manquant de maturité 12%

Source Ernst & Young, France, 2004

6. Conclusion

295Wattiau/Akoka Source : Assises de la sécurité – Livre blanc

296Wattiau/Akoka

6. Conclusion. Les inquiétudes

majeures des entreprisesvirus informatique, cheval de troie, ver internet 80%

"spams" 60%

pertes de confidentialité des informations relatives aux clients, atteintes à la vie privée 55%

vulnérabilités dues aux technologies sans fil 53%

attaque par déni de service distribué 49%

faute d'un salarié impliquant les SI 49%

faute commise par un tiers ayant accès à vos SI 49%

logiciels de qualité médiocre, non stabilisés 48%

sécurité physique 45%

vol d'informations propriétaires ou de propriété intellectuelle 40%

conformité à la réglementation 38%

fraude financière impliquant les SI 35%

Source Ernst & Young, France, 2004

J. Akoka297

6. Conclusion. Et en 2010 ?

Freins à la sécurité :

– le manque de budget,

– les contraintes organisationnelles,

– la réticence de la hiérarchie, des services ou

des utilisateurs,

– le manque de personnel qualifié,

– le manque de connaissance

(réponse des RSSI – CLUSIF 2010)