Madame, Monsieur,
veuillez trouver ci-dessous mes commentaires, en
réponse à l'appel à commentaires sur le guide "L'hygiène informatique en
entreprise - Quelques recommandations simples", publié à l'adresse
suivante :
http://www.ssi.gouv.fr/fr/bonnes-pratiques/recommandations-et-guides/securite-du-poste-de-travail-et-des-serveurs/appel-a-commentaires-sur-le-guide-l-hygiene-informatique-en-entreprise-quelques.html
Bien cordialement,
Christophe Pradier
http://cpradier.blogspot.comRemarques point par point(Les numéros se réfèrent aux numéros de règles dans vos documents.)
1.2) Ne pas oublier de situer dans la cartographie les VPN, la
télémaintenance et le télétravail, qui constituent des entrées/sorties
réseau à part entière.
Le lieu de stockage de la cartographie est un
point intéressant. Dans un premier temps, je pense qu'il vaut mieux
privilégier sa disponibilité et sa bonne mise-à-jour, en la protégeant
comme un fichier "sensible", plutôt que de la tenir entièrement
hors-réseau.
2) Ajouter "la liste des utilisateurs disposant d'accès à la configuration des équipements réseau".
Par
ailleurs, ces inventaires, quoique fort utiles, sont lourds à
maintenir. Dans mon expérience, le développement d'un ou deux petits
scripts qui mettent automatiquement ces inventaires à jour est peu
coûteux :
* tant vis-à-vis de l'achat de logiciels complexes sur la gestion des droits,
* de la maintenance manuelle de ces inventaires,
* que de l'absence de ces inventaires.
3.4)
Expliciter le concept : "mécanismes DE gestion DU contrôle DES
habilitations". C'est une chaîne logique loin d'être évidente pour des
néophytes.
5) Il faudrait préciser de quels "équipements personnels" l'on parle : smartphones, laptops, clés USB, clés 3G, wifi du voisin ?
6.1)
OK pour le côté client. Côté serveur, il faut également recenser (a
minima) les OS, les middlewares et les bases de données.
9) Dans le tableau "checklist" seulement, les points 9.1) et 9.2)
sont redondants avec le 3.1). Le point 9) du document texte "guide" est
mal repris dans le tableau "checklist".
Par ailleurs, il faudrait
préciser si la règle 9) s'entend uniquement pour le référentiel
d'identité principal (Active Directory en environnement Microsoft) ou
également pour les référentiels secondaires et applicatifs.
10) Les règles 10.2) et 10.5) ne sont pas et ne seront probablement
jamais respectées en PME. Dans des environnements PME, il est plus
efficace (cad respecté de façon homogène) de supprimer 10.1), 10.2) et
10.5), d'imposer un mot de passe unique mais fort et de le changer une
fois par an.
Ajouter une règle 10.7) "Si un mot de passe a été transmis, le changer
aussitôt." qui tombe sous le sens mais n'est pas listé dans vos
documents. Ça va sans dire mais ça va mieux en le disant.
11) Les règles 11.2) et 11.3) sont rarement à la porte technique et financière des PME intéressées par ce guide d'hygiène.
12.1) et 12.2) Préciser que "ne pas autoriser" correspond à une
démarche managériale de contrôle et de discipline, pas à un ensemble de
mesures techniques.
12.3) L'utilisation de SSO est très discutable.
Bien implémenté un SSO, même un simple SSO de navigateur web, peut aider
à augmenter la sécurité. En l'absence d'un vrai "projet SSO", il vaut
mieux, tristement, interdire cette fonctionnalité.
13) Remplacer "bien souvent" par "toujours". Inutile de minimiser ce problème de fond gravissime.
13.3)
N'est pas à la portée technique et financière des PME intéressées par
ce guide. Sur les 15 (chiffre factice) référentiels importants de la
PME, on aura les outils pour procéder au contrôle sur 2 ou 3, pas plus.
14) Insérer un 14.3) Interdire l'utilisation d'un code PIN par
défaut. Idem : interdire l'utilisation d'un code SOPIN par défaut.
17)
C'est un investissement de départ élevé mais tout à fait valable. Par
contre, les solutions du marché souffrent d'être souvent spécifiques à
un fabricant donné. Il faut faire des choix.
18) Là aussi, problème des produits vendor-specific.
18.2) Qu'entend-on précisément dans ce paragraphe par "politique de sécurité" ?
19.8)
Ce point est difficile à réaliser en pratique. Un moindre mal pourrait
être de s'assurer que le compte courant du téléassistant ne dispose pas
de droits d'administration.
19.9) Ce point me semble trop technique pour une PME néophyte. Des produits recommandés seraient une meilleure option.
19.12) Qu'entendez-vous par "l'ensemble des opérations de téléassistance" ?
* Si vous entendez "l'ensemble des sessions, horaires, acteurs...", OK.
*
Si vous entendez "l'ensemble des actions effectuées, dans le détail",
alors c'est complètement infaisable. En particulier dans le contexte
19.1) et 19.2), en raison de la nature extrêmement diverse des
interactions possibles, a fortiori pour des PME néophytes.
21.2) Un compte individuel ou... plusieurs pour les administrateurs.
Plutôt
que de disposer d'un compte "jean.dupont" individuel et d'un compte
"administrateur" partagé, il vaut souvent mieux disposer d'un
"jean.dupont.admin" nominatif et en profiter pour désactiver le compte
partagé "administrateur".
24.3), 27.1), 27.2) et 27.3) Qui dit supervision dit ressource
humaine pour superviser. Il faudrait donner une règle simple pour
déterminer quelle masse RH consacrer à la question.
24.4) Cette
question est très technique et nécessite des implémentations différentes
selon les "passerelles d'interconnexion". Pour connaître les machines
*internes*, il est souvent avantageux de faire appel tout de même au
DNS, car elles sont gérées par DHCP automatique.
28.1) Vaste et abstrait, pour un néophyte.
30) "Ne surtout pas faire d’exception pour les dirigeants de l'entreprise", insérer "ni pour les télétravailleurs."
32)
et 33) Dans les entreprises, la sûreté des locaux est souvent traitée
par un service différent de la sécurité informatique. Il serait bon de
préciser que les responsabilités doivent être clarifiées et que les
services doivent travailler ensemble.
36) Ajouter de toujours informer le RSSI d'une infection, même
mineure, même traitée sans difficulté, ne serait-ce que pour information
statistique.
37.0) + "Quelles sont les activités métier à redémarrer en premier ?"
38) + "Les utilisateurs, quand ils signalent un incident, doivent
être remerciés et tenus scrupuleusement au courant de la bonne prise en
compte/résolution/date prévue de résolution de l'incident."
39.1) Dans le tableau "checklist", la phrase est incomplète, il manque un verbe.
40) Pour une PME néophyte, sur quelle base demander un audit ?
Remarques générales
1/ Tous les points abordés dans vos documents sont valides mais trop
abstraits pour être abordés par des néophytes. En effet, si une
entreprise est à même d'embaucher un RSSI expérimenté à plein temps,
elle n'aura pas besoin d'une telle méthodologie simplifiée. Elle
s'adresse donc aux PME qui abordent pour la première fois une démarche
de sécurité.
La solution est d'illustrer un minimum les points abordés, en précisant bien que les exemples sont non-limitatifs.
2/ J'ai précédemment abordé la question d'une méthodologie de sécurité adaptée pour les PME dans l'article :
http://cpradier.blogspot.fr/2011/02/draft-step-by-step-security-approach.html3/
Retour sur le 22.1) Un document de récapitulation sur les principes de
DMZ, de cloisonnement... et leur mise en pratique serait
particulièrement bénéfique. Sous prétexte de cloisonner et sous la
pression de prestataires de services parfois peu scrupuleux, les PME
cloisonnent tout et n'importe quoi, sauf souvent l'essentiel.
Posts
