Retrouvez dans ce livre blanc 10 erreurs à ne pas commettre pour garantir la pérennité de votre système informatique.

1. Sécur ité
stra tégi
PRODU
us ag e
évolution
INFRA
STRUC
TURE
entreprise
AP PL IC AT IO N
DSI
plat efor me
pr esta tion
proc essus
Tech nolo gi
ma tériel
av an cé es
IT pe rfor
ma nc e
fournisseurs
architecture
prix
ENVI RO NNEMENT
Incidents de sécurité :
les 10 erreurs à ne pas
commettre
LesresponsablesenchargedelasécuritéduSystèmed’Information
ont généralement une grande confiance dans leurs pratiques et
dans la politique de sécurité qu’ils ont mis en place. Pour éviter
que les incidents de sécurité, par leur degré de gravité ou par
leur nombre, finissent par leur coûter leur poste, ils doivent faire
preuve d’une vigilance qui va au-delà de celle de leurs outils, tant
dans leurs quotidiens opérationnels que dans leurs interventions
auprès des salariés.
page 1
lan tation
évolut
sy stèm e
ma tépe rfor
ma nc e
logiciel
rv ic e
L TITU DE

2. pe rs
Im plan tation
CO NF IGUR AT ION
évolution
capa ci té
Cl o
DSI
sy stèm e
pr esta tion
virt ua lisé
av an cé es
pe r
ma
logiciel
architecture
serv ic e
MUL TITU DE
Un PC d’un utilisateur lambda attaqué, c’est un moindre
mal. Après tout, la machine de ce salarié ne renfermait
rien de critique, du moins pour l’entreprise. Tout au plus,
l’utilisateur souffrira-t-il de désagréments publicitaires
lorsqu’il naviguera sur le web. Peut-être même qu’il se fera
voler son numéro de carte bleue personnel s’il est trop
naïf. Par solidarité, la DSI se chargera de désinfecter sa
machine, mais après l’avoir un peu laissé méditer sur ses
visites sur des sites internet autorisées ou non. D’abord
pour qu’il prenne le temps de regretter son manque
de vigilance et qu’il retienne la leçon : l’application des
bonnes pratiques de sécurité concerne tout le monde,
ce n’est pas qu’un caprice d’informaticien. Ensuite, la
DSI doit montrer que sa tâche principale est le maintien
en condition opérationnelle du système informatique
de l’entreprise ; mobiliser des ressources informatiques
(critiques) pour secourir un utilisateur qui visite des
sites pas forcément de confiance et qui parfois peut
télécharger des logiciels pas toujours en relation avec
le travail, n’est pas une priorité. D’où un délai d’attente
pour l’utilisateur plus ou moins long
Problème, le PC infecté est sur le réseau de l’entreprise,
derrière le firewall. Le malware qui l’a infecté peut se
propager jusqu’au datacenter et infecter ses serveurs,
voire toutes ses machines virtuelles. Il y a un vrai risque
d’effet domino qui peut atteindre tout le SI en un rien
de temps. C’est ce qui est arrivé récemment dans
plusieurs cas de ransomware, où un malware parvient
en infectant d’abord un PC à chiffrer le contenu de tout
un datacenter, obligeant l’entreprise à verser une rançon
pour déchiffrer ses données. Il est à noter que, parfois,
la DSI n’a aucune intention de minorer l’attaque d’un
PC, mais elle ignore purement et simplement l’alerte de
sécurité qu’elle prend pour un énième faux positif. Outre
redoubler de vigilance, la bonne pratique consiste à
segmenter son SI et à le doter de moyens de traçabilité.
Minorer l’effet
d’une attaque
sur un PC
1
page 2

3. spect ive
ad minist ra tion
ou d C om pu ting
Tech nolo gi e
ma tériel
IT
rfor
nc e
isseurs
Une panne, une défaillance ou une attaque vient de
se produire. Pour y faire face sans plus attendre,
l’informaticienneperdpasdetempsàisolerlamachine
du réseau. Il y accède immédiatement en mode
administrateur, voire ouvre des ports dans le firewall
afin de pouvoir procéder à toutes ses réparations
sans entrave. En faisant cela, il ouvre une brèche...
qu’il oublie souvent de refermer ! L’ouverture de ports
dans le firewall est un classique qui peut aller jusqu’à
sa désactivation complète lorsqu’on veut s’assurer
qu’un problème vient bien d’une application ou d’une
machine et non d’une mauvaise configuration réseau.
La bonne pratique consiste à conserver une trace de
toutes les manipulations effectuées lors d’une telle
intervention, afin de rejouer le film des événements
à l’envers ensuite dans le but de refermer tout ce
qui a été ouvert. On vérifiera également, en fin de
procédure, quels ports sont toujours ouverts sur la
cible et si leur liste est cohérente avec les règles de
sécurité en vigueur.
2
Résoudre un
problème en
production
page 3

4. ad mnistr at ion
évoluti
ar ch itectur e sy stèm
virtu alisat ion
ge stion
logiciel
MUL TITU DE
Provoquer une panne sur un système n’est parfois qu’un
leurre de la part du pirate informatique dans le but de
consulter toutes les opérations qu’un administrateur
effectuera pour atteindre les ressources les plus
critiques du SI et vérifier si elles sont saines. Une fois
les opérations d’administration effectuées, l’attaquant
n’a plus qu’à consulter les fichiers de log sur la machine
de l’administrateur pour connaître les instructions
à taper qui le mèneront jusqu’aux organes les plus
critiques du Système d’Information. Si cette attaque
fonctionne, c’est parce que, contre toute attente, les
PC des administrateurs sont ceux qui se pénètrent le
plus simplement. En effet, selon une étude Insider Risk
Report 2015 menée cette année par Intermedia, les
informaticiens sont les premiers à ne pas appliquer les
bonnes pratiques qu’ils imposent aux salariés au sujet
des mots de passe : non seulement ils ne les changent
pas tous les 45 à 90 jours mais, en plus, ils ont pour
habitude d’utiliser le même pour tous leurs comptes, y
compris sur les médias sociaux. En général, un hacker
consulte la liste des salariés d’une entreprise, par
exemple sur LinkedIn, repère le nom d’un informaticien,
en déduit son login puis tâche de se connecter sur
l’un de ses comptes avec un générateur de mots de
passe. Lorsque la bonne combinaison est trouvée, il
se connecte à la machine de sa victime et consulte le
journal de ses interventions. Outre de la rigueur dans
la gestion de ses mots de passe, le bon réflexe d’un
informaticien devrait être de détruire le fichier de log qui
a répertorié toutes ses actions après une intervention.
Laisser des
traces de son
intervention
3
page 4

5. ma chin e
virt ue lle
ma téri el
DSIm e
ma térielpe rfor
ma nc e
architecture
serv ic
Lorsque l’on parle de virtualisation, il est essentiellement
question de machines virtuelles (ou VM. Des charges
logiciellessontpackagéesdansdes«VM»portéessurdes
machines dotées d’un hyperviseur. Ce dernier permet à
la fois de faire cohabiter plusieurs VM et de les déplacer
en temps réel, dans le meilleur des cas, afin d’optimiser
la charge des systèmes installés. Virtualiser revient donc
à optimiser des configurations traditionnelles, à faire ce
qu’on appelle une consolidation.
Mettre en place un Cloud privé, c’est revoir de fond en
comble l’ensemble d’un environnement autour de ces
machines virtuelles et, surtout, automatiser l’intégralité
des charges d’administration pour atteindre ce que les
spécialistes appellent l’orchestration.
Un Cloud privé repose sur une infrastructure qu’il est
possible d’administrer depuis une console centrale. De
là, la DSI, qui endosse le rôle d’un chef d’orchestre, pilote
l’ensemble des ressources du Cloud. Ce dernier dispose
des capacités pour assurer l’allocation automatique des
ressources matérielles et répondre aux variations de
charge des applications. Il assure aussi la gestion du
cycle de vie desdites applications.
Cette souplesse, que les anglo-saxons dénomment
élasticité ou agilité, est propre aux environnements en
Cloud. Elle va bien au-delà des avancées apportées
par la virtualisation d’applications. Ainsi, une architecture
de Cloud privé est-elle à même de prendre en charge
la coordination de datacenters distribués, capables
de s’épauler automatiquement les uns les autres et
d’assurer un niveau de redondance.
4
Éliminer un
logiciel en se
contentant de
l’effacer
page 5

6. budinterfac e
PROJET
erv ic e
pa ra mè tre
co
sy stèm e
utilisa teur ge
clou d
prod uc tion
TR
AP PLI
CA TION
fonctionnel
an a lys e
mé tier
C’est un grand classique : on n’applique aucun patch,
aucune mise à jour de sécurité à un système ou un logiciel
en production de peur que cela crée une incompatibilité
et rende le SI inopérant. Seulement voilà, la plupart des
SI sont compromis non pas à cause d’une faille ‘zero
day’ (une faille exploitée avant même qu’elle ne soit
connue des antivirus et firewalls), mais d’une brèche qui
perdure depuis plus d’un an. Moralité, il faut appliquer
les patchs qui paraissent régulièrement... après avoir
testé sur une machine isolée qu’ils ne provoquent aucun
dysfonctionnement. Si tel était le cas, la bonne pratique
consisterait à passer en alerte rouge : il faut prévenir
le fournisseur et le presser de trouver une solution. Le
problème est si épineux - patcher au risque de tout
casser ou ne pas le faire au risque de se faire attaquer
- que le responsable de la sécurité aura tout intérêt à se
couvrir en mettant toute sa hiérarchie au courant de la
Ne plus
toucher à un
système qui
fonctionne
5
situation, afin que la responsabilité d’appliquer ou non un
patch ne pèse pas sur ses seules épaules. A ce sujet, il
est important de noter qu’un responsable de la sécurité
ne devrait jamais reporter au DSI, mais directement au
PDG. Enfin, selon la dernière étude annuelle State of
IT Changes Survey de NetWrix, les patchs provoquent
généralement des dysfonctionnements parce que la
moitié des informaticiens apportent des modifications
à leur SI sans les documenter, ce qui conduit les
entreprises à ne pas installer les bonnes mises à jour.
page 6

7. BUDGET
dge t
ra pp ort
o ût
Ré flex ion
e stion
trai teme nt
n
RAITEMENT
prix
prestation
Faire du zèle est la principale cause de licenciement des
responsables de la sécurité informatique. La priorité de
l’entreprise n’est pas la sécurité, c’est son business.
Alors, même lorsque tout le SI est corrompu, les
dirigeants de l’entreprise préféreront encore maintenir
en fonctionnement les systèmes qui assurent les
revenus, plutôt que tout couper pour sécuriser le SI et
se débarrasser des hackers. Cela s’appelle la brèche
assumée : on continue l’activité coûte que coûte,
même avec des malfaiteurs qui accèdent librement aux
données. Les dommages seront de toute façon moins
importants que la mise à l’arrêt de l’activité, enfin, c’est
ce qu’on croit ! La bonne solution est donc de trouver
une parade furtive à l’attaque, qui ne dérange pas la
bonne marche de l’entreprise. Ce sera techniquement
plus compliqué, mais c’est le sésame pour conserver
son contrat de travail.
Cette règle s’applique également à la sécurité du poste
du PDG. Il ne faut jamais tenter de contraindre un PDG à
ne pas surfer sur certains sites ou à remplacer son mot
de passe tous les quatre matins. Le PDG ne trouverait
pas normal de ne pas avoir tous les droits et de voir ses
usages rendus trop complexes en raison des mesures
de protection légitimes visant ses équipements. Là
encore, il faut se montrer inventif en assurant une sécurité
invisible. Les responsables de la sécurité autoritaires
n’ont plus voix au chapitre de nos jours.
6
Être un
responsable de la
sécurité trop zélé
page 7

8. proc essus
système
co mp étence
op timisat ion
In
inf ra stru ctu re
cur ité
CR YP
ma térie
ENVI RO NN
str
DIME NSION
OUTIL
tâch
Au prétexte d’une enquête interne suite à un problème
de sécurité, un administrateur peut techniquement
user de ses droits informatiques sur le réseau pour
accéder aux données personnelles des salariés. Sauf
que c’est formellement interdit par la loi. L’administrateur
perdra son poste dès que l’on saura qu’il a fouillé
dans des données qui ne le concernent pas. En
général, les informaticiens argumentent qu’il leur suffit
de ne pas se faire prendre. Mais cela ne fonctionne
jamais : l’administrateur va forcément tomber sur des
informations dont la connaissance va le pousser à se
découvrir. Dans le pire des cas, il se vantera d’avoir le
pouvoir de le faire et ses propos remonteront toujours
jusqu’à sa hiérarchie. Voire, il se servira des informations
découvertes pour faire chanter ou harceler un collègue
- c’est plus fréquent qu’on le croit- ce qui engendrera
une enquête, laquelle débouchera sur des poursuites à
son égard. Dans le cas le plus classique, l’administrateur
tombera sur des informations qu’il jugera nécessaire de
dévoiler soit au bénéfice de ses collègues (ébauche d’un
plan social, en préparation dans le dossier d’un directeur
administratif, typiquement), soit à celui de l’entreprise
(contenu à caractère criminel sur le disque d’un salarié).
Mais la preuve de l’existence de ces informations passe
forcément par l’explication de leur découverte et donc la
mise au grand jour d’une action illégale.
La bonne pratique est de s’en tenir au strict cadre de
la loi, de ne jamais fouiller dans les données privées et
de laisser des fonctionnaires le faire si le droit l’exige.
Mais le plus important pour un administrateur est surtout
de prouver au reste de l’entreprise qu’il n’usera jamais
de son pouvoir technique de fouiner. Et cela se fait en
allant voir les salariés pour leur montrer comment crypter
leurs données… avec une clé que l’administrateur ne
possède pas.
Au niveau des procédures, les changements les plus
importants concernent la mise en place et la maîtrise
d’outils de pilotage. Ils servent à l’automatisation, à la mise
en libre-service et à l’orchestration de ces ressources
d’un genre nouveau. En parallèle, des compétences
devront être formées et des outils déployés pour suivre
les coûts de Cloud et leur refacturation en interne.
Chercher des
preuves dans des
données privées
7
page 8

9. mobi lité
ressou rc
protect ion
n tern et
Ré flex ion
TAGE
el
procéd ur e
NEMENT
ra tégi e
technique
iel
innovation
LS
e
Suite à une attaque, c’est décidé, on remplace la
solution informatique vieillissante (Windows Server
2003, typiquement) par un système dernier cri. Bien
évidemment, pas question de migrer à l’aveugle. La
DSI fait une maquette : elle teste la bonne marche
des applications et la compatibilité des données en
production sur un serveur de test, spécialement préparé
avec les dernières versions de Windows ou Linux. Ce
système d’appoint, absolument pas prévu pour la mise
en production, est déployé rapidement et n’est pas aussi
bien protégé que le reste du datacenter. A dessein : tous
les audits de sécurité nécessaires prendraient trop de
temps, alors qu’il est urgent de valider la modernisation
du SI. Seulement voilà, aux yeux d’un hacker, un serveur
de test est un serveur comme les autres mais sur lequel
voler ou corrompre tout le contenu s’avère souvent
plus aisé. Sachant cela, la bonne pratique consiste à
ne surtout pas tester le fonctionnement d’un nouveau
système avec des données réelles, de sorte que si une
cyberattaque a lieu sur les machines de tests, elle n’ait
aucune conséquence.
8
Tester un
nouveau système
avec des
données réelles
page 9

10. projet
stra tégi e
utilisa teur
do
Ré flex io n
éd iteu r
sécur ité
ma tériel
CHAN GEMEN
stra
qualité
novation
in for ma tiq
Un antimalware ne protège que des failles connues.
Mais les pirates publient désormais des centaines de
milliers, si ce n’est des millions de codes malveillants
chaque mois, soit bien trop pour quelque solution de
sécurité - antivirus, firewall... - que ce soit. De fait, les
attaques dites de zero day exploitent en vérité des failles
qui restent ouvertes bien au-delà d’une simple journée.
Parfois, l’antidote n’existe pas avant des semaines,
quand ce n’est des mois. Il en va de même pour le
pare-feu, de plus en plus inefficace. Car le principe
des attaques modernes n’est plus tant d’attaquer un SI
depuis l’extérieur en passant par un port ouvert, mais
de convaincre un utilisateur de télécharger un logiciel
malveillant sur son PC depuis une simple navigation
web, d’apparence anodine. Pire, le malware prendra
ses ordres d’un attaquant extérieur en l’interrogeant via
le port 80 ou 443, c’est-à-dire en se faisant lui-même
passer pour une simple requête émise par un salarié qui
consulte un site web lambda. La pratique de la sécurité
n’est pas un logiciel ou un ensemble d’outils, mais bien
un métier. Le responsable de la sécurité doit se doter
des outils et avoir les ressources nécessaires (humaines
et informatiques) qui lui permettent de surveiller l’activité
du SI et d’intervenir manuellement ou faire intervenir des
experts si besoin est
Laisser faire
le dispositif de
sécurité
9
page 10

11. serv ic e
am éliora tion
protect ion
o nn ée s
offresl
ENTRE PRISE
NT
a tégi e
dé ve lopp emen t
conception
TEST
qu e
Le responsable de la sécurité du SI a fait le job : il a
sensibilisélessalariésàlanécessitéd’appliquerlespatchs
de sécurité sur leurs postes et à ne pas cliquer sur telle ou
telle fenêtre qui apparaît lorsqu’ils naviguent sur Internet.
Pourquoi dès lors le tiendrait-on pour responsable si ces
mauvais élèves d’utilisateurs contaminent encore leurs
PC ? Hé bien parce que la formation des salariés est
généralement inefficace. Selon Roger A. Grimes, un
écrivain américain spécialiste en sécurité, la première
erreur du RSSI consiste à ne jamais vérifier que les
utilisateurs installent bien les patchs. Parfois ils n’y arrivent
pas et n’osent pas l’avouer, car le responsable de la
sécurité a une approche souvent autoritaire qui n’invite
pas au dialogue. Parfois, ils effectuent bien les mises à
jour de Windows et des principales applications métier
qu’ils utilisent, mais oublient de patcher les modules les
plus courants de leurs postes - Java, Adobe Reader ou
encore Flash ; il faut dire que cela paraissait tellement
évident au RSSI qu’il n’a pas jugé utile de leur en
parler… D’autres fois encore, les salariés sont tellement
conditionnés à tout sécuriser, qu’ils valident les yeux
fermés toutes les demandes de mise à jour.... y compris
quand il s’agit de la fenêtre pop-up d’un malware sur le
web qui prend l’apparence d’un antivirus ! Roger Grimes
note à ce propos qu’on enseigne en moyenne tous les
deux ans aux salariés quelles fenêtres sont des faux
antivirus, alors qu’un hacker change tous les deux jours
l’apparence de ses malwares, de peur qu’ils ne soient
déjà reconnaissables. Ici aussi, la pratique de la sécurité
doit passer par des interventions régulières. Mais qui ne
doivent jamais paraître trop pesantes.
10
Ne pas mettre
correctement
en garde les
salariés
page 11