Publication du Guide d'Hygiène Informatique par l'ANSSI

Suite à mon envoi de commentaires en décembre, j'ai reçu ce petit courriel de l'ANSSI :

de Communication (SSI)
à Moi

Bonjour,
L’ANSSI vient de publier le guide d’hygiène informatique.
Vous pourrez le trouver sur le site Internet de l’ANSSI : www.ssi.gouv.fr/hygiene-informatique  
N’hésitez pas à nous contacter si vous désirez recevoir le guide au format papier.
Nous vous remercions encore pour votre contribution à l'amélioration de ce guide.

Cordialement,

Le bureau communication de l’ANSSI

Alors comme ça, le guide est paru ? Histoire de mener chaque chose à son terme, je me décide à vérifier quelles remarques parmi les miennes ont été prises en compte. Il y a 28 points concrets dans mes commentaires. Résultat du parcours du nouveau guide :

64% des remarques que j'ai formulées ont été prises en compte sous une forme ou sous une autre. Il faut nuancer les 36% restants. En effet, certaines remarques s'entendent dans un contexte qui serait long à expliquer dans un tel guide. L'ANSSI doit faire des choix, aussi tout ne peut pas être retenu.

J'apprécie extrêmement le professionnalisme de certaines agences gouvernementales, notamment la CNIL et désormais l'ANSSI :

1. Publier un draft.
2. Appeler à commentaire.
3. Publier une version corrigée.
4. Remercier les personnes qui ont commenté et les inviter à télécharger le document.

Ça, c'est une façon de travailler.

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.

Appel à commentaires sur le guide : « L’hygiène informatique en entreprise - Quelques recommandations simples »

L'ANSSI lance un appel à commentaires :

Protéger les données et le réseau informatique des entreprises est aujourd’hui crucial pour leur survie et leur compétitivité. A cette fin, l’ANSSI a réalisé un guide d’hygiène informatique destiné aux entreprises et présentant 40 recommandations simples pour sécuriser leur(s) systèmes d’information.

Afin qu’il puisse répondre à vos attentes et besoins, l’ANSSI souhaite recueillir votre avis sur ce projet.

Les observations, commentaires et propositions de modifications pourront être envoyés jusqu’au 15 novembre à l’adresse suivante :

communication [at] ssi.gouv.fr

Guide d’hygiène inform­atique
PDF - 651.3 ko

Check List
PDF - 265.3 ko

Draft: A Step by Step Security Approach for SMBs

Suppose you're a newly appointed CISO in a SMB. Suppose that position is a creation.

I've had to think about it as I'm currently advising a few fellow CISOs. They're in positions where IT security is just one of their responsibilities because the structure is not big enough to afford a full-time CISO. The rest of their time, they act as IT project manager, network administrator or company's archivist!

In this position, you may want to have a look at comprehensive guides/norms/references about IT security. But how to handle an ISO 27002? How to handle an ISO 27001 when it's a newly created job and you can't muscle into decisions? How to spread awareness that you don't want to do everything in those norms, but only the most important ones for a small structure?

I recommend the following steps, in the approximate order I give. (Experienced security people might be surprised that I don't place the policy and the charter at the top...)

First steps: gather documentation, work alone
You're going to write documents that will follow you everyday on your work and that you'll want to have at hand even in the corridors of your workplace. I call them the "Books of..." for this reason.

1. Write the Book of Activities in which you'll list every task that IT people think it's their job to do. You can do that by striding through IT documents, chatting with every IT people and doing a week in the Service Desk (or equivalent)
2. Write the Book of Services in which you'll list every Activity that's sold to the end-users (whether in speech or money). For each of them, list the description of the population of end-users and the arguments used to sell the service. For instance, "the firewall" is an activity but not a service because it's transparent to end-users. "Mailboxes" is both.
3. Write the Book of Legal Constraints in which you'll list the precise references to legal texts and their implications for you. You'll have to do it one day, so better do it from the beginning.
4. Write the Book of Classification in which you'll note what special kind of information deserves what special kind of treatment. For an SMB, I would suggest to only consider legally-constrained classification. For instance, classify medical data or military data, but don't go into making classified categories such as public, private, secret, top-secret, HR-only or anything so detailed.
5. Write the Book of Risk Analysis in which you'll create a grid (basically a sieve or even a checklist of threats that might occur to your information system) to think about risks whenever needed. That will be especially useful at the beginning of any IT project that you want to secure. You'll be more confident because you'll follow a long-time established list and people will trust what you say more because it won't have popped out of thin air.
6. Write the Book of Integration Requirements which you'll append at the end of any RFP, in which you'll list all of the technical conditions the chosen solution will have to fulfill. It will also be helpful if your company does some internal development, you'll just have to distribute it to developers. You can get that list by going to network and system administrators and asking them for what went bad in their past integration experiences. You'll get 90% of it in just 30 minutes of discussion.
7. Write the Book of Physical Security Requirements, which you'll forward to people in charge of electricity, building access control, fire prevention and so on.

Second steps: set up inventories, work with the admins
You're going to make sure you know your assets, you know your perimeter and you're going to make sure that IT people don't get lost into the mess of an IT service. (Tcha-tching!)
For these steps, you'll have to initiate the work but the admins will have to keep up on the long run.

See, that's not just writing docs, that's about having the right information to make the right decision when needed. That's about billing customers with exactitude. That's about enabling statistics on the activities.

1. Make sure you have an Inventory of Users, which may include all employees, contractors, providers and customers. Once you have that, you'll be able to work on identification and authentication. (Please ensure that an authentication project is never started before the identification is correct. Even if this sounds too stoopid to happen.)
2. Find or create the Inventory of Network Equipments.
3. Find or create the Inventory of Endpoint Computers (desktops, laptops, macs, iphones, huge display screens...) You'll usually find one or more partial inventories when you arrive in the company. It is part of the CISO's job to make sure that this inventory is not partial.
4. Find or create the Inventory of Printers (and other multimedia hardware).
5. Find or create the Inventory of Servers.
6. Find or create the Inventory of Server Software.
7. Find or create the Inventory of IT-Managed Endpoint Software.
8. Find or create the Inventory of Providers and related SLAs.
9. Find or create the Inventory of Network Flows and Zones. Internet, VPNs, mailing service, DMZs...
10. Find or create the Inventory of AntiVirus Software and AntiSpam Software (or the Inventory of Not-AntiVirused Flows and Not-AntiSpammed Flows if that's quicker).

When you've made sure the inventories listed above are up-to-date, you can say you've reached your cruising speed. You can start auditing, advising, collecting data to prove an intuition, intervening in a decision process, etc.

Third steps, cruising speed, work with strategy people
Now, you're aware of your perimeter, you have a good overview of the risks, you may even formulate a strategy. You'll want a few more tools to formulate it, have it approved and execute it. Listed below are the main tools of the CISO. They're in no particular order, contrary to above. You may use them at your convenience.

• Metrics. Once you've decided a technical point, measure the degree of conformance to this decision. Once you've set your objectives, display your progression publicly.
• Supervision and logs. Realtime supervision will give teams the power to act before the Service Desk gets a call from users. Logs will help the teams go back on an incident and prevent its re-happening.
• Redundancy and High-Availability. If you've spotted a specifically sensitive point in the information system (like the central user directory, or the billing system), ensure they are redounded and can switch from one to the other within minutes. That alone saves your company days of lost work a year and saves the IT service days of cold sweat.
• Software Update. A big risk is associated with old versions of software (not just vulnerabilities, I mean: bugs, difficulty for the Service Desk to master multiple versions, impossibility to remotely detect the version, longer phases of test for the integration of new software/hardware, etc.) So get a piece of software to detect installed software, versions, and remotely distribute updates.
• User Charter. The users want to be told what to do plus they need to be told what not to do. Additionally, you gain immediate influence and respect of the Charter just by mentioning that someone actually is in charge of IT security. Try to make a new version every year, don't put too much but make sure the basics are never forgotten.
• Information Security Policy. This document affirms, company-wide, the separation of responsibilities in terms of information security and this is the place where you can get the CEO or the Board to sign that you have the autority to do a specific thing. Usually, it's not made for anything technical, it's made to sort internal power struggles or budget affectation. It's boring for the CEO, so don't make more than one new version every two years but make sure you get support on the most difficult human and managerial issues you encounter.
• Risk Management. A risk is a sum of money or time that the company loses because of the happening of a threat. When you know the threats, when you know their probability of happening, you can estimate a risk and treat risks in descending order. That's called risk management (I saved you a book!) A CISO usually gets that by gut feeling, but it's always good to confirm it with analysis and it's better to show that you don't decide on things just by gut feelings. You can see it as a way to help others make decisions about IT security (CIO, CEO, budget planner...)