La plupart des développeurs ne connaissent pas la sécurité, selon Akasha Security

**Malick** · 03/04/2017, 18h52

Cybersécurité : la plupart des développeurs ne connaissent pas ce qu'est la sécurité,
selon Akasha Security

La sécurité de nos systèmes d'information revêt un caractère très important, car les conséquences liées à une mauvaise sécurisation des données peuvent être très fâcheuses ; cela aussi bien pour les entreprises que pour les particuliers. En effet, les conséquences d'une mauvaise sécurisation se traduisent souvent par la diffusion d'informations confidentielles à l'instar des coordonnées bancaires, de la situation patrimoniale, des codes confidentiels, etc. La sécurité est donc l'affaire de tous et tout un chacun doit être au moins initié sur les différentes conduites ou précautions à adopter afin d'assurer la sécurité des données. Cependant, une attention particulière est portée à l'endroit des développeurs, car ces derniers ont en charge le développement des différents outils que nous utilisons dans la vie de tous les jours. Du fait de leur rôle, ces derniers devraient être à l'aise sur les différents aspects liés à la sécurité afin de les intégrer dans les outils qu'ils mettent en place.

Cependant, suite à une étude qu'elle a menée, la société Akasha Security vient de publier un rapport dans lequel elle met en évidence l'insuffisance d'une formation adéquate pour les développeurs en matière de sécurité. Akasha Security estime que durant leur cursus universitaire, rares sont les développeurs qui bénéficient d'une formation intégrant des modules adéquats traitant de la sécurité. Selon lui, la majeure partie des développeurs qui ont cette compétence sont soit formés par leur employeur dans le cadre de leur travail, soit ils ont cherché eux-mêmes des formations adaptées.

Il est utile de préciser que Akasha Security est une société spécialisée dans la sécurité des systèmes d'information et son siège social se trouve à Houston au Texas.

Pour étayer son argumentaire dans son rapport, le spécialiste en sécurité affirme avoir interviewé un développeur diplômé qui a même écrit une application Web actuellement en production pour son université. « Le développeur en question ne connaissait même pas en quoi consistait le hachage ou salage de mot de passe avant de les stocker dans une base de données », a soutenu Akasha Security. Pour le spécialiste, cela n'est pas surprenant puisque les universités ne jouent pas correctement leur rôle notamment en enseignant la sécurité à leurs étudiants. Rappelons que le salage est une méthode permettant de renforcer la sécurité des informations qui sont destinées à être hachées (par exemple des mots de passe) en y ajoutant une donnée supplémentaire afin d’empêcher que deux informations identiques conduisent à la même empreinte. Le hachage par contre consiste à calculer une donnée de petite dimension à partir d’une donnée de grande dimension afin de s’en servir comme repère dans différents processus algorithmiques ; son objectif n’est donc pas de chiffrer des données, mais de donner une « empreinte » à une donnée.

Afin de mieux défendre ses arguments, Akasha Security a rappelé les conclusions d'une étude qui a été menée en 2016 par CloudPassage Study. En effet, l'étude de ce dernier révélait que les universités américaines avaient failli à leur mission de formation dans le domaine de la cybersécurité. Les conclusions relatives à cette étude se présentaient comme suit :

dans le top 10 des meilleurs programmes de formation en informatiques aux États-Unis, aucun cours portant sur la cybersécurité n'a été identifié ;
trois des 10 meilleures universités ne proposaient même pas de cours en sécurité ;
sur les 36 meilleurs diplômes en sciences de l'informatique, un seul intègre un cours portant sur la sécurité ;
sur les 50 premières universités, seules trois proposent des formations en sécurité.

Dans son rapport, le spécialiste en sécurité attire l'attention sur le fait qu'aujourd'hui, de grosses sommes d'argent sont dépensées chaque année par les sociétés, cela pour faire soit une évaluation de la vulnérabilité de leurs applications Web, soit pour faire des tests d'intrusion, etc. Les entreprises s'attachent également les services d'experts à qui elles versent beaucoup d'argent en heures de développement afin de corriger certaines failles qui auraient pu être évitées par les développeurs. Selon Akasha, pour une meilleure rentabilité et plus de sécurité, il est plus sûr et plus efficace de former les développeurs en amont. Une formation adéquate permettra à ces derniers d'avoir une certaine confiance en eux et de pouvoir intégrer les aspects liés à la sécurité dans leur code ; ainsi en cas de problème, ils pourront travailler en synergie et en toute quiétude pour identifier les parties en cause.

« Il est important que les équipes d'assurance qualité aient une formation en sécurité. Les développeurs, les testeurs et les gestionnaires devraient également tous connaître le Top 10 OWASP à un strict minimum. », a déclaré Akasha Security. Rappelons que l'OWASP (Open Web Application Security Project) est une communauté en ligne travaillant sur la sécurité des applications Web et sa vocation est de publier des recommandations de sécurisation Web et de proposer aux internautes, administrateurs et entreprises des méthodes et outils de référence permettant de contrôler le niveau de sécurisation des applications Web. Il a élaboré une liste des dix risques de sécurité applicatifs Web les plus critiques.

S'adressant aux entreprises, le spécialiste en sécurité affirme qu'une formation régulière à la sécurité pour les développeurs et les testeurs vous garantit que les nouveaux employés seront bien formés. Akasha Securit ajoute que « beaucoup de développeurs passent plus de temps à maintenir des applications plutôt que de chercher à accroître leurs compétences. Or il peut être difficile de rester au courant des récentes évolutions et changements aussi bien en termes de développement qu'en termes de sécurité si votre rôle à temps plein est de produire du code. Les développeurs ont besoin d'être régulièrement formés par des experts de la sécurité afin de se mettre à jour sur les dernières techniques et outils. »

Source : Akasha Security

Et vous?

Que pensez-vous des conclusions du rapport d'Akasha Security ?

Partagez-vous son avis ?

**emutramp** · 03/04/2017, 19h49

hachage ou salage de mot de passe avant de les stocker dans une base de données

Un développeur web ne connaissant pas les bases de son métier n'en est pas un. De même un étudiant qui choisi sa course IT doit au moins y connaître ses débouchés et l’avenir de son futur métier.

Commencer des études de 2 / 3 ans dans une branche IT a laquelle les bases de celle-ci ne sont inconnus ou non acquises (sur les tech du moment) est un suicide professionnel programmé

Après, la sécurité c’est vaste et ça ne date pas d’hier et la responsabilité d’une parti de celle-ci est notamment du au développement trop rapide voulu par quelques grosses boites tech au prix de la performance, sécurité, long terme.

Un image de la sécurité IT global actuelle pourrait être de la comparer a un produit «*Made in China*»*

**marsupial** · 03/04/2017, 21h04

Lorsqu'on voit l'évolution de la complexité des attaques ces 10 dernières années, on ne peut qu'être inquiet d'une sécurité gruyère made in China.

Celle-ci par exemple, attaque in-memory sur au moins 140 banques et organismes gouvernementaux, avec uniquement des outils existants, pas la moindre ligne de code retrouvée pouvant déterminer l'auteur de l'attaque, et surtout indétectable sans audit spécifique, laisse présager de sombres temps à venir pour la sécurité des données.

La sécurité à la conception va coûter 1 sur une base 100. La sécurité lors du déboguage va coûter 50. La sécurité en préproduction va coûter 100. La sécurité en production devient variable et peut impliquer de reconcevoir entièrement l'application. Ce petit métrique devrait entrer dans la tête de tous les décideurs avant de valider quoi que ce soit. Le problème devient le discours. Un technicien ne sera pas vendeur. Au contraire du marketeux qui estime que le paramètre sécurité reste négligeable car pas dramatique. Et surtout n'apporte pas de valeur immédiate au produit.

Pour parler du sondage, par expérience, j'ai commencé par enseigner à un petit noyau de personnes le code sécurisé. Ce petit noyau a ensuite diffusé aux 22 000 ingénieurs de l'entreprise ce qu'ils avaient appris. L'un d'entre eux a délivré une formation d'une semaine aux responsables sécurité des pays de l'OTAN. Une semaine n'a pas suffit à tout leur apprendre. De cette expérience, je dois dire que les développeurs sont insuffisamment formés à la sécurité. Mais pas que les développeurs.

**emutramp** · 03/04/2017, 23h14

De cette expérience, je dois dire que les développeurs sont insuffisamment formés à la sécurité. Mais pas que les développeurs

Cette phrase m’a donne envie de pousser un peu plus sur les détails, car c’est un point important et et exact.

Tous le monde est concerné, beaucoup d’information sur le sujet et pourtant rien ne change concrètement. Plusieurs raisons*:

1) Mensonge continuelle ou désinformation des firmes / société en charge d’un produit, système ou autre, compromis par une vulnérabilité (CVE, 0day…) misant sur la communication pour se défaire du problème*:

1) Communication du genre «*Nous avons corriger la vulnérabilité et nos équipes ont analysées le code etc. Nous garantissons que l’intégrité de notre système et sa sécurité est désormais hors de danger» ← Corriger un problème de sécurité confirme que seul le bug en question a était traitée , il faut pousser encore plus loin et prévenir revoir l’ensemble de l’infrastructure contre l’utilisation ou corriger des vulnérabilités similaire.

2) Sécurité par obscurité*: L’utilisation de code source ferme devrait être interdit a l’exception d*‘organisme militaire, gouvernemental (si la protection de secret sont en jeu) ou pour un usage privé (j’oublie peut-être quelques cas d’utilisation légitime…). Offrir un code source ferme aux publiques est déjà un problème de sécurité évident*: L’impossibilité de faire un audit complet sur ce qui est proposé et peut des lors, contenir du code cache comme un backdoor ou autres gros problèmes de conception pouvant mener des intrus a l’utiliser

3) Par facilite, pour l’argent, par fainéantise, par corruption, par intérêt commercial, pour contrôler, par déni de remise en cause des responsables (qui balanceront la patate chaude a quelqu’un d’autre) …

4) Par stupidité, facilité, déni de réalité : Quasiment tous le monde sait qu’un smartphone / tablettes sont utilisés a souhait par n’importe qui ayant des capacités suffisante pour s’y introduire (loin d’être compliqué), faire l’autruche pour garder un petit confort technologique aux prix de ruiner la démocratie et les libertés acquises en offrant un accès a une grosse parti de vos informations privées (en temps réel…). Pas besoin de vous espionner constamment, il suffit d’enregistrer tout ce que vous faite sur 5, 10 15 ans... et le jour ou ils en auront besoin, ils s’en serviront (imaginez que vous soyez journaliste d’investigation, vous avez une affaire politique dérangeante a révéler, ils pourront vous en dissuader en vous menaçant de révéler des choses privées sur vous…)

Ce n’est pas très populiste comme discourt, certes, mais voyant que même après des révélations sur ce sujet faisant état d’abus grave sur des libertés individuelles a l’échelle de la planète fait par quelques courageux, prenant des risques ultimes (peine de mort, prison a vie, couler avec les fondations d’un immeuble en construction) pour que celles-ci soient transmise au publique, les gens ne changent que très peu leurs pratiques et alimente ce système anti-démocratique (et cerise sur le gâteau, vous le financez)

**Spinoza96** · 04/04/2017, 04h44

En effet je suis diplômé en génie logiciel.
Ce genre de diplôme est très general et m'offre les possibilité d’accéder à n'importe quel type d'emploi dans l'informatique.
Je n'ai en revanche reçu aucun cours en sécurité malgré que je sois, soit disant qualifié pour être administrateur réseau/ BD ou développeur web.
La sécurité ne m'attire pas, certe il y a certaine petite pratique importante lorsqu'on développe une architecture mais rien de plus.
Je prefere créer et laisser les autres protéger mes créations.

**Iradrille** · 04/04/2017, 05h23

Envoyé par Spinoza96

En effet je suis diplômé en génie logiciel.
Ce genre de diplôme est très general et m'offre les possibilité d’accéder à n'importe quel type d'emploi dans l'informatique.
Je n'ai en revanche reçu aucun cours en sécurité malgré que je sois, soit disant qualifié pour être administrateur réseau/ BD ou développeur web.
La sécurité ne m'attire pas, certe il y a certaine petite pratique importante lorsqu'on développe une architecture mais rien de plus.
Je prefere créer et laisser les autres protéger mes créations.

Un minimum est requis (et fait parti du taff). Si quelqu'un doit repasser sur chaque ligne de code que tu écris à la recherche (+ probable correction, si c'est quelque chose que tu ignores ou choisis d'ignorer) d'un buffer overflow ou problème de conversion signé / non signé ou autre c'est une perte de temps énorme.

M'enfin, s'occuper de la sécurité : ça demande du temps et des compétences , et donc ça coute cher.

Ne pas s'en occuper : osef c'est le client qui se fait baiser. Et vu que personne ne s'en occupe, le client ne peut même pas espérer trouver mieux chez les concurrents.
Dans le cas où l'entreprise perd des données stratégiques, elle envoi une armée d'avocats, et gagne automatiquement le procès.

Une entreprise n'a aucun intérêt à protéger ses systèmes.
Et les gouvernements n'ont aucun intérêt non plus à forcer les entreprises à sécuriser leurs systèmes, vu que ça rend l'espionnage plus difficile.

C'est totalement stupide, mais tant qu'il ne se passera pas quelque chose de grave : prise du contrôle du réseau électrique ou des transports (trains / avions); rien ne changera.

**Spinoza96** · 04/04/2017, 05h33

Je suis tout à fait d'accord comme j'ai dit lorsqu'on développe il y a certaine pratique ou réflexe qui différencie le bon du mauvais code.
Et en general du code propre c'est aussi un code qu'on ne peut tromper ou casser.
Comme j'ai dit je n'ai aucune formation en sécurité j'ai toujours pensé qu'il s'agissait uniquement d'une des branches de la réseautique.
Or moi mon truc c'est les algorithmes meme lorsque je développe sur des bases de donnée, tout ce qui est mise en réseau ne me concerne pas.

**emutramp** · 04/04/2017, 06h59

Un minimum voir les bonnes manières pour chaque parti en charge d’un réseau doit être fait en terme de sécurité*:

- Un dev web qui utilise le PHP doit connaître les erreurs qui peuvent amener a un trou de sécurité lorsqu’il code (injection SQL / faille include / ne jamais faire confiance au client…)

- Un dev reseau ou systeme qui utilise le C doit connaître les erreurs qui mène a des over bufferflow et autre technique utilisant des bugs mémoire…

- Un admin réseau se charge des règles de transition des paquet / firewall / limite les accès par utilisateur / vérifier les logs…

- Un admin système se charge de mettre a jour / entretenir / patch / hardened…

Imaginez ces 4 spécifications se retourner contre un type en charge de la sécurité, lui refoutant sur le dos leurs propres erreurs qui ont mené a une vulnérabilité d’être exploitée

**marsupial** · 04/04/2017, 08h00

Je sais que tout le monde ne travaille pas dans un domaine sensible. Mais imaginez la faille sur le site web qui permet ensuite de fouiller le réseau et de voler les données sensibles d'une entreprise. Du style données commerciales ou juridiques. Cela peut être la catastrophe et vite devenir dramatique. Pourtant écrire un code sécurisé s'apprend. Ce n'est pas apprendre à coder en soi. Il s'agit juste de franchir le cap d'avoir une pensée pour la partie hack et de réfléchir hacking en créant ou debuggant.

Dans mon cas, les 22 000 ingénieurs ne sont pas tous des développeurs d'origines mais ils ont tous à développer ou concevoir un peu de code. Par exemple, hors de question de voir une escadrille de drones prendre la poudre d'escampette ou un satellite militaire tomber parce que l'ingé n'a pas pensé à coder sécurisé.

Mais la sécurité restera toujours l'affaire de tous. Depuis le concepteur jusqu'à l'utilisateur.

Apple fournit ce qu'il y a de plus sur au monde mais pourtant nous avons entièrement écrit un protocole de communication sécurisée pour remplacer celui fournit par le constructeur car la norme accordée par les Etats-Unis à ses entreprises est largement trop faible pour nous. On ne joue pas avec la destinée d'une entreprise de 68 000 employés aux contrats secret Defense en considérant la sécurité comme négligeable. Ou dépendant du seul RSSI.

Et je pense que, même sans être dans un domaine sensible, beaucoup d'entreprises devraient objectivement avoir le même point de vue.

**leroivi** · 04/04/2017, 09h05

J'ai eu une petite sensibilisation à la sécurité à l'école, dans mes cours de réseaux (où on designais et configurais une infrastructure) et dans mes cours de cryptographie (on a eu quelques notions théoriques et mathématique et le prof aimais bien nous montrer quelques trucs à l'aide de root-me.org) mais, premièrement, cela restais très marginal à coté des autres cours, on y a pas passé beaucoup de temps, et, deuxièmement, j'ai surtout peur pour la suite, comment continuer à être au courant des bonnes pratiques de sécurité en tant que développeur ? comment vais-je savoir qu'il ne faut plus utiliser tel ou tel méthode car elle sont devenue facilement cassable ?

**spawntux** · 04/04/2017, 09h08

Bonjour,

De mon point de vue il y a un grand manque de compréhension des fonctionnements de base, encore plus en france, la vision depuis quelques années etait " la sécurité ? ca ne me rapporte pas d'argent je vais pas prendre des gars pour ca. En plus ca ralentie nos process et c'est chiant".

C'est toujours le cas dans de nombreuse boite avec une optique sécurité négative ou les décisionnaire n'ose pas imposer ce genre de chose par peur de la réputation politique en interne que celui ci pourrait avoir.

Dans des grands groupe des personnes ayant la connaissance sécu n'ose pas car un monsieur au dessus qui n'y connais rien a dit que "la sécu ca sert a rien".

De mon point de vue on y est pas encore mais ca viendra.

PS: Le patch management est un gros sujet de debat en grosse entreprise

**hotcryx** · 04/04/2017, 10h35

Si tu penses que ça ne te rapporteras rien, regarde donc ce que tu peux perdre

**spawntux** · 04/04/2017, 10h59

Envoyé par hotcryx

Si tu penses que ça ne te rapporteras rien, regarde donc ce que tu peux perdre

Tu prêches un convaincu, mais malheureusement ca ne suffit pas toujours

**transgohan** · 04/04/2017, 11h50

La sécurité c'est un véritable métier donc bon...
Je travaille sur de l'embarqué critique donc avec des experts en sécurité.
Mais je me vois mal apprendre tout ce qu'ils font...
On peut avoir des bases, mais suivant le projet/produit et sa destination il est parfois nécessaire d'avoir plus qu'un développeur sensibilisé à la sécurité.
Le jeu revient à une gestion des coûts gain/perte... Et c'est bien malheureux.

**marsupial** · 06/04/2017, 06h05

Nous ne savons pas comment feront d'autres entreprises. Mais à la vue de la politique de confidentialité de Windows 8.x et 10, au delà de l'interface à chier, elle devient rédhibitoire dans notre cas et a engendré une migration complète et une entière refonte du SI en intégrant comme paramètre central la sécurité. Tous les softs maisons ont été transpilés et revus de fond en comble à la lumière de ce paramètre. Cela a demandé aussi un examen en profondeur de la portabilité des softs fournisseurs orientant vers une solution de virtualisation en nuage privé, non seulement plus sure mais beaucoup plus pratique à administrer et simple pour l'utilisateur.

Lors des tests de validation auprès des utilisateurs qui d'habitude subissent les migrations plus qu'ils les vivent, le premier a fait un soleil, le deuxième nous a dit que cela répondait exactement à ses attentes, le troisième en est tombé de son fauteuil, etc ...

Au niveau comptable, cela a demandé un travail minimal de la DSI en regard de l'ampleur du chantier et une baisse drastique des coûts, cadet de nos soucis, dès la première année d'exploitation pour un niveau de maîtrise et de sécurité incomparable sur le marché. Et ça, ça n'a pas de prix pour nous.