Des chapeaux et des boîtes : les bonnes pratiques en matière de sécurité

Soumis par Tris Acatrinei le Mardi 15 mai 2012 à 10:17

*Ecrit avec la participation de Sebdraven*

Il a été précédemment évoqué le fait que les entreprises ne faisaient pas suffisamment attention à la sécurité de leurs infrastructures.

Selon leur degré de vigilance, elles ne sont pas à l'abri d'une personne mal intentionnée qui aura envie de s'amuser un peu avec la sécurité de leur système. Quelles sont alors les bonnes pratiques à adopter ? 

La sécurité doit obéir à cinq objectifs qui sont issus de la norme ISO 27001 : 

  • Intégrité
  • Confidentialité
  • Disponibilité 
  • Non répudiation 
  • Authentification   

L'intégrité suppose une garantie quant à la véracité et à l'authentification des données et donc une surveillance constante sur ce qui peut circuler comme données dans un système. 

La confidentialité repose sur une bonne gestion des permissions également appelée gestion d'habilitation. De manière radicale, il convient de jouer les dictateurs dans certaines hypothèses et de ne laisser la main sur les infrastructures qu'à un nombre très limité de personnes. Dans l'hypothèse où un problème survient, il sera beaucoup plus facile de retracer l'origine de l'erreur et donc de la corriger. 

La disponibilité implique une maintenance constante afin de garantir un bon fonctionnement des systèmes. 

La non répudiation concerne de façon quasi-exclusive les systèmes gérant des données bancaires et des transactions commerciales dans la mesure où cet objectif doit répondre à une garantie de non-rejet d'une transaction. 

L'authentification rejoint l'objectif de confidentialité et demande l'assurance de l'accès aux ressources par les personnes disposant des droits adaptés.

Ces objectifs nécessitent que lors de la création du système, les bons outils ont été mis en place : des protocoles de transfert sécurisés, du chiffrement, du matériel récent. Vient ensuite la question des permissions qui doivent être en nombre limités. Seules les personnes ayant impérativement besoin dans le cadre de l'exécution de leur mission, de hautes permissions doivent les obtenir. Fournir des permissions à des accès spécifiques à des personnes qui non seulement n'en ont pas besoin mais qui ne comprennent pas le système est non seulement inutile mais dangereux. 

Une fois le système mis en place, adopter une politique de mot de passe rigide n'est pas une mauvaise idée. Le changement de mot de passe respectant une certaine périodicité peut aider à maintenir un niveau correct de sécurité. De la même manière, imposer une certaine longueur et une certaine mise en forme peut aider, par exemple, des mots de passe de huit à dix caractères minimum avec des majuscules, minuscules et au moins un chiffre. Certains utilisent des mots de passe comprenant entre 15 et 20 caractères, répondant aux règles précédemment énoncées, avec un changement tous les mois ou tous les deux mois.

Programmer des sauvegardes régulières et les stocker dans un espace à part, accessible pour un nombre restreint de personnes constitue une habitude à prendre. 

Enfin, des audits de sécurité sont à programmer de façon régulière sans pour autant en informer l'ensemble de la hiérarchie. Il convient alors d'opérer en white, grey et black box car certaines failles ne sont détectées que dans l'une de ses trois configuration. Reste alors la question de savoir qui va opérer ces audits. Si les ressources existent en interne, il ne faut pas hésiter à les utiliser, sinon, passer par des personnes dont la sécurité des systèmes est le coeur de métier est une évidence.  

Les points précédemment abordés sont axés sur les entreprises et les systèmes professionnels mais peuvent tout autant s'appliquer à des infrastructures personnelles. Pour certaines personnes, s'attaquer à des particuliers est beaucoup plus intéressant et parfois moins risqué que de s'attaquer à des entreprises ou des institutions. S'astreindre à ce type de formalités peut éviter bien des embêtements. 

L'idée générale qu'il convient de retenir est qu'il faut adopter les mêmes habitudes de prévention en informatique que celles utilisées et pratiquées dans la vie réelle. 

Commentaires

kerrubin (non vérifié)

Tuesday 15 May 2012 à 10:52

A noter, sur la gestion des mots de passe qu'une politique trop stricte est souvent contre productive.

Si l'on doit changer régulièrement de mot de passe, certaines personnes ne voudront/pourront pas s'en souvenir (d'autant plus avec la multiplication des applications et donc mots de passe).

Encore plus quand le mot de passe se doit d'être complexe.

Il y a donc le risque d'avoir le mot de passe noté sur un post-it collé à l'écran (ou derrière le clavier), ce qui est souvent pire.

De la même manière, il est pertinent d'avoir des processus de délégation de pouvoir.

Exemple : si une personne part en vacances, sans délégation, elle donnera son mot de passe à son collègue pour qu'il se connecte en son nom.

Avec délégation, le collègue continuera à se loguer avec son propre compte.

Se pose aussi, pour le grand public, des processus de récupération de mot de passe.

De nombreux sites le mettent en place, mais cela peut être un trou de sécurité plus ou moins important.

Et ce, même avec des questions de sécurités (du type "quel est ta date de naissance ?", "quel est le nom de jeune fille de ta mère ?" qui peuvent être déduites/trouvées par du social engineering, tout comme les mots de passe, trop souvent).

Pour les audits, il n'est pas toujours utile d'en faire.

Sur certains applicatifs, il suffit de parler avec les développeurs pour obtenir la liste des failles de sécurité.

Ils en sont parfois (très/trop) conscients, mais la volonté de la hiérarchie n'est pas d'avoir de la qualité/sécurité (mais plutôt du quick and dirty qui fonctionne au moment de la livraison).

Mais pour satisfaire tous les points listés (intégrité, confidentialité, disponibilité, non répudiation, authentification), il faut que le tout s'insère dans une réflexione globale. Ce qui ne pourra jamais être fait quand le cahier des charges tient sur un coin de table ou dans un mail.

La sécurité, en entreprise, est plus pensée comme une perte potentielle de notoriété/crédibilité que comme un réel problème ("c'est l'autre qui peut être piraté, pas moi").
Ce qui revient à ton autre article : La sécurité : le parent pauvre des entreprises.
Tant que le préjudice subit des entreprises sera inférieur au gain (de temps/argent) de la non-sécurisation, rien ne bougera.

A voir, par exemple, si Sony sécurise mieux ses données.

Tris Acatrinei

Tuesday 09 April 2013 à 22:51

Le problème étant de trouver le juste milieu entre une politique trop rigide et une politique trop souple. Je pense qu'il faut l'adapter en fonction des besoins, des échelons et des compétences ainsi que des sphères concernées. Par exemple, lorsque tu as une machine personnelle chez toi, que tu vis seul et que tu ne reçois personne, tu n'as pas non plus besoin d'appliquer les mêmes choses que lorsque tu travailles en entreprise, dans un open-space avec 7 autres personnes.
Effectivement, la procédure de récupération de mot de passe est en elle-même une faille de sécurité. Facebook a mis en place une politique quant à la sécurité des mots de passe assez rigolote (ça fait l'objet d'un article qui sera publié dans quelques temps).
Pour les audits, ça dépend des structures et surtout de leur sensibilité.
Effectivement, commencer par remplir un cahier des charges prend du temps,demande de la réflexion, des informations, des recherches, tu ne fais pas ça attablé(e) sur un coin de table au bistro du coin. Et oui, il faut une véritable prise de conscience quant à l'importance de la sécurité informatique, de préférence avant qu'arrive une grosse catastrophe, cf Sony. 

btreguier (non vérifié)

Tuesday 15 May 2012 à 12:00

Bonjour, Totalement d'accord avec l'analyse de "kerrubin" concernant le traitement de l'expiration des mots de passe. D'ailleurs, un certain nombre de personnes, et pas des moindres puisque parmi elles on trouve Bruce Schneier (qu'on ne présente plus), commencent à se poser des questions sur le bienfondé de cette pratique. En fin de commentaire, quelques liens parlant du problème, dont 1 papier (dernier lien) analysant le niveau d'entropie présenté par un nouveau mot de passe choisi par un utilisateur, dès lors qu'on connaît ses anciens mots de passe: il se trouve qu'elle est souvent insuffisante, et ce indépendemment des autres pratiques risquées tendant à se manifester en cas de politique un peu trop bridée (post-it sous le clavier quand ce n'est pas carrément sur l'écran, etc.). Tous les liens ci-dessous ne sont pas aussi tranchés et ne préconisent pas aveuglément de conserver le même mot de passe ad vitam aeternam, mais ils ont le mérite de poser la sempiternelle question: "le mieux n'est-il pas l'ennemi du bien" ? En d'autres termes, ne vaut-il mieux pas éduquer ses utilisateurs afin que ceux-ci choisissent un *bon* mot de passe, quitte à le faire durer (beaucoup) plus longtemps que ce que préconisent habituellement les politiques de sécurité "standards" ? D'ailleurs, d'où vient-elle, cette durée ? Quelles sont les menaces sur la confidentialité d'un mot de passe ? - les logiciels de découverte style John, Cain&Abel, etc. ? En règle générale, avec des logiciels comme ceux-là et les puissances disponibles maintenant, un mauvais mot de passe tombe en quelques minutes ou quelques heures. S'il tient au-delà, il y a de grandes chances pour qu'il ne soit jamais trouvé... Si on voulait être cohérent, il faudrait donc changer de mot de passe tous les jours, voire plus souvent. ;) - les keyloggers ? Si on en a un qui se planque sur sa machine, tout changement de mot de passe est vain... - les gens qui regardent par dessus votre épaule ? Si vous avez un doute sur le fait que vos frappes clavier aient pu être espionnées, votre mot de passe compromis, la réaction doit être immédiate et faire suite à l'événement en question, elle ne doit pas être basée sur une durée précise... En bref, je n'arrive pas, pour ma part, à trouver de bonne raison pour un changement régulier et imposé. Mais c'est mon avis. :) Finalement, la vraie question serait plutôt: utilisé seul, le mot de passe peut-il encore être considéré comme un moyen sûr d'authentification ? Ne devrait-il pas être systématiquement complété par autre chose (token, biométrie, etc.) ? Bonne journée...

B. Tréguier

Les liens:

CERIAS : Security Myths and Passwords
The Security of Modern Password Expiration: An Algorithmic Framwork and Empirical Analysis
When To Change Passwords - Dark Reading
Password Expiration Considered Harmful | Cryptosmith
Password Expiration: Like Margarine and Water? « Speaking of Security – The RSA Blog and Podcast
The Security of Modern Password Expiration: An Algorithmic Framwork and Empirical Analysis

Tris Acatrinei

Tuesday 15 May 2012 à 14:24

Hello et bienvenue déjà :)
Je suis d'accord avec l'idée d'éduquer la masse sur la question des mots de passe mais le fait est que la plupart des personnes ne s'y intéressent pas du tout. Quant à JTR, Abel&Cain, cela concerne surtout les mots de passe en local d'après ce que j'en ai compris.
Keyloggers oui, les gens qui regardent par-dessus les épuales, pas faux du tout mais tu peux élargir aux codes d'entrée aux portes des immeubles, au code de carte bancaire, etc.
Le changement régulier - dans le cadre d'une entreprise - permet d'éviter certaines fuites qui peuvent être notamment dues au BYOD (Bring Your Own Device).
Token, pourquoi pas, mais biométrie, en ce qui me concerne, c'est non et non ! :)
Je lis ce que tu m'as laissé en lien :)

kerrubin (non vérifié)

Tuesday 15 May 2012 à 14:58

En open-space, ce qui marche bien, c'est quand la session est pas lockée, y a un petit malin qui envoie un mail avec "j'apporte les viennoiseries", "j'aime les hommes" (avec photos à-la-con à l’appui), changement du wallpaper pour un boys band coréen ou autres conneries (jamais méchante). Ca marche du tonnerre ! :) Mais oui, la sécurité doit s’adapter, c’est juste qu’actuellement, elle est souvent sacrifié sur l’autel des coûts directs (en sacrifiant par la même occasion les coûts de maintenance et évolution…). Comme tu l’as dis avec raison, Tris, les gens sont trop peu formés, les mentalités de la hiérarchie n’évoluent pas assez rapidement vis-à-vis des dangers potentiels. Et étant donné que c’est la hiérarchie qui recrute également, ça veut dire que les profils avec formations à la sécurité ne sont pas forcément recherchés. Du coup, il y a impasse sur la formation en sécurité (je parle de ceux qui font les applications, là, à plus forte raison les prestataires en SSII). Après, pour la complétion d’un mot de passe avec autre chose… C’est discutable, pour le token par exemple : comment le stocker, prouver qu’il est bon… Ca reviendrait à avoir un token/certificat personnel qui serait utilisé partout. Donc, remise en question de la gestion des certificats et…on revient au point de départ. Pour la biométrie, même chose, cela suppose un fichier permettant de relier une identité (exemple associer « kerrubin » à une empreinte digitale), donc protéger le fichier contre le piratage… Donc, j'ai quand même du mal à y croire, hélas... Au final, la sécurité doit effectivement être relative à ce qui doit être protégé. Ceci dit, il y a toujours des best pratices et autres éléments assez basiques à mettre en place (et souvent sans gros efforts superflus). Mais la sécurité reste aussi beaucoup plus globale. Companies Lose $2.5 Million from Missing Memory Sticks, Study Says Je lis aussi les liens mis à dispo !

Tris Acatrinei

Tuesday 15 May 2012 à 15:11

Je vais lire ça aussi avec attention :)

Krumpf (non vérifié)

Tuesday 15 May 2012 à 14:52

Bonjour ! Je ne m'y connais que peu en sécurité informatique, mais je tiens néanmoins à montrer ce dessin (from xkcd) et cet article qui en explique en partie le pourquoi.

P.S. : Félicitations à la Tris pour son nouveau site et bonne continuation ! ;-)

Tris Acatrinei

Tuesday 15 May 2012 à 15:09

Merci le Krumpf ! :)

btreguier (non vérifié)

Tuesday 15 May 2012 à 16:11

Rebonjour et merci pour les voeux de bienvenue. ;)

Concernant la biométrie, j'ai la même défiance que vous, je pense. Je la citais simplement en exemple, mais le simple fait, déjà, que ça ne soit pas révocable, ça pose un sacé problème. Je n'ai pas forcément envie de changer mes doigts ou mes yeux (quoique, pour ces derniers...).

Pour les découvertes de mots de passe par les logiciels adéquats, en effet c'est essentiellement du local, mais rien n'empêche de s'en servir dans un 2ème temps, après avoir récupéré un fichier intéressant de ce point de vue via une 1ère attaque type injection SQL ou autre...

Quant au BYOD, oui, c'est un sacré problème, mais pas qu'au niveau des mots de passe ! Mon avis personnel à moi que j'ai, c'est qu'on n'a pas "le cul sorti des ronces" avec ça (passe-moi l'expression), mais on n'a pas le choix, faut faire avec... Nomadisme, évolution des méthodes de travail, et génération Y obligent.

Ici, pour les mots de passe, ce qu'on fait (et c'est marqué dans notre charte), c'est qu'on fait régulièrement tourner JTR et consorts, et tout utilisateur dont le mot de passe a été trouvé voit son compte bloqué automatiquement. Du coup il est obligé de passer nous voir, et on lui explique en le sermonnant un peu, que la prochaine fois il faut qu"il évite de choisir un dérivé du nom de son chien ou la plaque d'immatriculation de sa voiture... On n'est pas méchants (peut-être qu'on devrait ?) mais bon, avoir à venir s'expliquer un peu trop souvent, ça finit par être gênant. Donc on compte sur les vertus éducatives de cette méthode... Ce n'est certes pas une panacée, tout juste un pansement, en espérant que ce n'est pas sur une jambe de bois. ;)

Bonne journée !

Tris Acatrinei

Tuesday 15 May 2012 à 17:11

J'aime bien ton idée ! :D

btreguier (non vérifié)

Tuesday 15 May 2012 à 19:17

On s'était interrogés sur la légalité de la chose à l'époque de la mise en place (il y a déjà bien longtemps), puisque ça implique quand-même l'utilisation d'outils assez offensifs, mais on s'était dit que comme nos utilisateurs étaient au courant et acceptaient la chose via la signature de la charte, après tout, on pouvait y aller franco...

Depuis que la LCEN a introduit l'article 323-3-1 (qui réprime la possession illégitime de moyens techniques d'attaque), on devrait peut-être se reposer la question, mais pour l'instant c'est toujours en place. La vraie question, ici, c'est celle de la légitimité, finalement... Dans la mesure où on fait ça pour le bien de nos utilisateurs et la sécurité de notre système d'information, je suppose qu'on peut considérer que ça l'est. ;)

Tris Acatrinei

Tuesday 15 May 2012 à 20:28

A mon avis, à partir du moment où les salariés sont informés, que la hiérarchie est au courant et l'a accepté, il ne devrait pas y avoir de problèmes. Les moyens d'attaques sont des outils à la base, c'est la façon dont on s'en sert qui peut être illicite/illégale. 

Ajouter un commentaire