Le pense-bête pratique de la sécurité

La sécurité ? Mais diable, pourquoi moi ?

Et bien il se trouve que la sécurité numérique, c’est l’affaire de tous. Je ne vais pas te le prouver ici, mais il faudra me croire. Toi qui codes avec tes élégantes mains, et ton cerveau bien fait, qui abondes chaque jour à un projet magnifique qui te rapportera peut être de l’argent, sache que l’appli, le service, l’interface fait partie d’un tout. Et que dans ce tout, le point le plus vulnérable aux attaques par logiciel ou physique, sera le point le plus robuste de ta solution. Je te laisse relire cette phrase.

Voilà. En gros, il suffit qu’il y ait une faille quelque part, même petite, pour que ton système entier soit poreux. Il suffit que ton château fort contienne un tunnel pour que l’ennemi pille en silence ton garde-manger en hiver ou se pointe tranquilou-bilou à l’heure de la soupe. Évidemment, cela dépend de la faille. Si le tunnel est tout petit, seuls les petits animaux rongeurs pourront passer.

Par ailleurs un attaquant claustrophobe n’attaquera pas avec la même efficacité qu’un grand gaillard entraîné à se tortiller dans la boue. Bref, une vulnérabilité ne causera pas toujours les mêmes dégâts, selon sa nature et la personne qui l’exploite, mais quand même. Mais, mais quand même.

Tu l’as compris, une certaine pression repose sur les épaules des artisans du web. En plus de coder propre et quali, il s’agit aussi de faire de la sécu et de protéger le château. Comment ? En se disant que de toutes les façons, il y aura bien un petit malin qui sautera la première défense, mais il ne devra pas passer la seconde. Il pourra creuser un tunnel, mais tombera sur une herse.

Donc, toi, développeuse, développeur, architecte, dev-ops, tu as une responsabilité : tenir les défenses du château. Y arriveras-tu tout seul ? Non, je ne te le cache pas. Il te faudra discuter avec presque tous les autres artisans qui fabriquent ce château. Et c’est là que la sécurité, ça devient cool, on rencontre plein de gens.

Connais ton château, trouve ton « precious ».

Connaître ton château, c’est la clé. Il te faut connaître son périmètre, les choses précieuses à protéger, les trucs qu’il faut garder secrets, les « my precious » à ne partager avec personne. Car il te faudra savoir où mettre tes efforts pour construire tes défenses les plus hautes. Soyons concrets. Tu développes un service en ligne qui permet de faire de la recommandation ultra pointue aux visiteurs basée sur une multitude de paramètres, grâce à un algorithme plus que secret, qu’un chercheur a mis des années à affûter. Il serait dommage qu’en cliquant droit, ton concurrent puisse directement avoir accès à l’algorithme en question, ou qu’il puisse l’utiliser directement depuis son site, en mode open bar.

Ton « precious », c’est ton algorithme de recommandation.

Bref, tu l’auras compris, chère développeuse, cher développeur, il faudra doubler les barrières là où tu risques de perdre le contrôle de ton « precious ». Et évidemment, il n’y a pas de recette universelle de défense puisqu’il existe de larges variétés de business models, et donc une large variété de choses matérielles ou immatérielles à protéger.

Pour certains, ce sera un algorithme, ou une base de données, ou l’identité de leurs utilisateurs, ou encore ce sera la liste des numéros de carte bleue (dans ce cas précis, la réglementation bancaire t’imposera quelques obligations), ou enfin le logiciel embarqué qui pilote une voiture autonome. Pour d’autres, le bien le plus cher sera la marque elle-même, ou encore de la propriété intellectuelle.

Certains « precious » seront du côté des serveurs, d’autres du côté des applis, bref, il te faudra connaître d’où provient la valeur de la solution que tu développes, et connaître ce qui contribue le plus au revenu de celui qui te paye. En cela la sécurité t’oblige à lever le nez, et à comprendre le monde dans lequel tu évolues, à aller interroger tes collègues.

Note que si tu es ton propre patron et capitaine du business que tu codes, tu as gagné ici le droit d’une bonne bière au calme pour lister les choses qui font la valeur de ton business, et leur donner une priorité, bref, un brainstorm entre toi, et toi-même, en tête à tête – tu me remercieras plus tard.

Hop, hop, hop. Et les données personnelles !

Jusqu’ici, nous avons parlé des éléments clés à protéger pour maintenir un business en sécurité. Sache, également, développeuse, développeur, que la loi te pousse à commettre quelques améliorations sécuritaires, sous peine d’amende. En effet, à partir de mai 2018, rentrera en vigueur une réglementation qui oblige chaque entité manipulant des données personnelles d’utilisateurs, à les protéger, au même titre que les « precious » précédemment cités.

Cette réglementation est appelée RGPD (on ne t’en voudra pas d’inverser une ou deux lettres de cet affreux acronyme, d’autant que la version anglaise est appelée GDPR, voilà, tu es perdu, pardon). RGPD, donc, Règlement Général sur la Protection des Données, exige que toute entité qui récolte, stocke, transfère ou manipule des données personnelles le fasse en étant assuré que l’utilisateur a explicitement donné son accord, que l’usage des données lui a été expliqué, que seules les données pertinentes ont été collectées, et que les utilisateurs ont contrôle sur les données (comprennent, peuvent demander de les effacer).

Il faut également que les données soient transférables vers un autre service, et que la durée de stockage soit connue, justifiée. Je te la fais rapide, hein.

Et le dernier point important, est que l’entité qui manipule ces données doit tout faire pour protéger les données contre un accès non-souhaité, une fuite, du vol. Ah ? Nous y voilà. Devant la loi, tu as obligation de protéger correctement les données de tes utilisateurs. Si tu ne le fais pas, et que les données sont perdues, volées, …

Et d’une, il te faudra prévenir ton utilisateur que ses données ont été volées.
Et de deux, c’est l’amende, 10 % du revenu.
Si tu veux tout connaître du RGPD, tu peux aller butiner par ici, Nicolas Courtier a écrit une belle série de billets clairs et précis sur le règlement en question.

Et maintenant ?

Voilà. Maintenant que tu sais à peu près quoi protéger (ton « precious » et les données personnelles de tes utilisateurs), il serait bien que tu saches comment les protéger. Évidemment, je ne vais pas pouvoir te livrer ici le bouclier magique qui te protégera de toutes les attaques. En revanche, il y a les basiques :

  • communiquer en chiffrant le canal avec HTTPS,
  • gérer proprement les cookies et fin de session,
  • chiffrer ses données stockées,
  • ne stocker que les hash de mot de passe,
  • segmenter correctement ses accès aux données ou informations sensibles.

Ouaip, ça, c’est la base de la base.

Et comment apprendre plus et implémenter correctement ?

Je dirais : pas à pas.

En expérimentant. Il existe un certain nombre de ressources qui te permettront de parer au plus évident. Par exemple, cette liste de contrôles basiques éditée par l’OWASP pourra t’aider.

Et, la liste des 10 attaques les plus classiques, le top 10 de l’OWASP, complétera ton éducation. Il y a des blogs pertinents, comme les blogs de Mozilla, ou Google (pardon). Il y a un bon podcast qui donne la parole aux experts sécu, c’est NoLimitSecu .

Je recommande également la lecture de Ars Technica Security, ou ThreatPost, ça peut paraître un peu du niveau securité expert, mais cela permet de se familiariser avec le vocabulaire et les notions de sécurité. Chaque faille commentée dans ces média est une facette de l’histoire de la sécurité.

Petit à petit, j’ai confiance, développeuse, développeur, que tu gagneras en compétences.

Voilà, voilà. Nous voici au bout de cet article sur la sécurité.

Et presque à la veille de Noël. Il ne me reste qu’à te souhaiter de beaux projets de vie pour les années qui viennent, c’est quand même aussi sacrément important.
#bisou
Virginie

Ps : Ho. Pour la sécurité. Et je suis dispo sur @poulpita, et je réponds toujours poliment et au mieux aux questions de sécu. Soit moi-même, soit en redirigeant vers les experts ou ressources qui vont bien. N’hésite pas à me contacter. #Rebisou.