Wednesday, October 17, 2012

Commentaires à l'ANSSI sur le guide "L'hygiène informatique en entreprise - Quelques recommandations simples"

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


Remarques 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.html

3/ 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.