Accueil > Développement, Sécurité > [SSI] Sécurité des Systèmes d’Information

[SSI] Sécurité des Systèmes d’Information

Cela fait plusieurs fois que je vis un audit de sécurité.
L’existant aidant, parfois, ça se passe bien, parfois non.
Mais cette fois, cela a été suivit d’une petite formation.

Pour moi, c’est intéressant à plusieurs titres. Le premier, c’est le client : son but est d’avoir des applicatifs plus sécurisés. Ensuite, pour ma société (ITECOR) : c’est l’un des « subject matter » (sujets transverses à nos différentes activités). Et enfin, c’est intéressant à titre personnel.

Tout le monde est donc gagnant.

Je vais donc parler un peu de la sécurité à travers plusieurs billets.
Ce premier billet va être l’occasion de parler de la SSI en termes généraux.
Et pour cela, je vais m’inspirer d’ITECOR et de son WHY/WHAT/HOW.

 

WHY – Pourquoi faire de la sécurité ?

 

Parmis les gros piratages qui font tâches, on peut en citer plusieurs.

Déjà, le FBI : 15-year-old Teenage Hacker Arrested Over FBI Computer Hack.
Cela prouve deux choses : personne n’est à l’abri, d’une part, et d’autre part, que le piratage n’est pas le fait de quelques sombres mafias ou de hackers à cagoules dans un garage (astuce : ne pas développer dans le noir, ça fait méga mal aux yeux ; je n’ai pas tenté avec la cagoule, ceci dit).

Le piratage d’Ashley Madison, le site de rencontre adultère, est édifiant.
Le vol de données a provoqué des suicides, chantages et de nombreux problèmes sociaux.
Pour l’entreprise, si l’on met de côté l’image de marque qui en a prit un sacré coup, il y a aussi des suites judiciaires : Ashley Madison Hit With $500 Million in Lawsuits.
Mais les pertes financières sont probablement le moins dommageable : It will take years to count the true human cost of the Ashley Madison hack.

Le piratage informatique existe depuis les début d’Internet. Dès 1988, Robert Tappan Morris écrit le ver Morris, qui causera entre $100,000 et $10,000,000 de pertes (c’est large, comme fourchette, mais bon…).

Le piratage est donc très loin d’être un fait nouveau, mais il se démocratise.
En effet, avec le développement d’Internet et le fait qu’il devienne omniprésent – y compris dans les infrastructures critiques : Pirater une centrale nucléaire, c’est plus facile qu’on imagine -, il y a de plus en plus d’applicatifs vulnérables.
De plus, les ressources sur Internet pour expliquer comment pirater sont légions, les outils deviennent de plus en plus accessibles (exemple : metasploit) et les failles de sécurités de plus en plus documentées (exemple exploit-db).

Comme on peut le voir, l’impact peut se mesurer en termes d’image (souvent le moins problématique), en perte financière (qui pourra tuer certaines entreprises) ou parfois en pertes humaines.
Un piratage est donc loin d’être neutre.

Les pirates de Sony découverts, plus d’un an après ?

Pour les piratages plus « légers », on peut citer les DDoS qui ont touchés le PSN ou la BBC ou encore EDF (avec un préjudice financier de l’ordre de 160 000 euros).

Guillaume Poupard, président de Agence Nationale de la Sécurité des Systèmes d’Information avait ces mots, lors des Assises de la Sécurité 2015 :

Le cas de TV5 […] est un cas emblématique non pas par la difficulté qu’il y a de s’attaquer à ce genre de cibles mais par le fait que, dorénavant, quasiment n’importe qui peut être une cible.

Cyberattaque de TV5Monde : « On est dans une guerre de l’information ».
Le bilan est assez…lourd : Cyberattaque – La sécurité coûte des millions d’euros à TV5 Monde.

Le site web géré par Troy Hunt, have i been pwned?, permet de voir si l’une de ses adresses mails a été sujette à un vol. Il y a un formulaire de notification pour savoir dès que son adresse est concernée et, depuis peu, il a ajouté un opt out. D’ailleurs, son blog est des plus intéressant.

 

WHAT – De quoi on parle ? Pourquoi aussi peu de sécurité ?

 

Après cette introduction volontairement alarmiste (quoique…), une question importante : de quoi parle-t-on quand on dit « Sécurité des Systèmes d’Information » ?

Quand on parle de Sécurité des Systèmes d’Information, on parle d’un domaine TRES vaste.
En effet, la sécurité commence dès le physique : c’est-à-dire l’accès aux bâtiments (vidéo surveillance, badges…), l’accès aux serveurs (limitations aux personnes autorisées…)…
Il y a aussi tout ce qui est infrastructure réseau (le matériel, VPN, DMZ, pare-feu (firewall), IDS, accès wifi…).
Viennent ensuite tout ce qui est systèmes d’exploitation (RAID, virtualisation…).
Et en dernier les applicatifs (gestion identification/authentification, SSL…) et les données (intégrité…).
Il est possible de faire de un inventaire à la Prévert de tout ce qui est impacté par la sécurité.

Dans le cadre de ce blog, je vais me borner à la Sécurité du Système d’Informations et surtout à la séucrité des applicatifs.

La sécurité ne s’envisage pas réellement de façon simple en disant : « je suis protégé, j’ai un firewall/IDS/WAF (Web Application Firewall)/antivirus/… ».
La sécurité, au sein d’une entreprise, est avant tout un problème de gouvernance.

Depuis quelques années, l’Open Web Application Security Project publie régulièrement un TOP 10 des failles les plus critiques sur les applicatifs web.
En reprenant leurs résultats et en les croisant, on peut réaliser le tableau qui suit :
TOP-OWASP
Je ne vais pas dire que c’est toujours les mêmes, mais quand même… Et ce, depuis au moins 10 ans.

Ensuite, il faut aussi bien comprendre que la sécurité à 100% n’existe pas.

La sécurité, ce n’est pas avoir un SI inviolable. C’est avant tout le rendre suffisemment complexe (pour l’attaquant, hein, pas pour ceux qui font les maintenances…) et long a attaquer pour que l’attaquant passe à autre chose. Ni plus, ni moins.

De plus, il ne faut pas oublier que les attaquants peuvent aller du Script Kiddie à une puissance d’Etat (La Chine reconnaît enfin l’existence de ses hackers). Un « attaquant » peut également être une personne qui n’est pas forcément mal intentionnée, mais qui modifie une URL et accède à quelque chose de normalement inaccessible.

Certains ont donc plus de moyens, plus de temps et des intérêts plus importants pour attaquer que d’autres.

Donc, pourquoi il y a aussi peu de sécurité ?
A mon sens, plusieurs pistes.
La première, c’est la culture de l’entreprise. Si elle n’est pas orientée « technologie », il y a des chances que ceux qui pilotent les projets concidèrent les applicatifs comme un peu « magiques » et n’ai pas forcément conscience du problème.
L’existant vient ensuite. Il est plus simple (et plus efficace) de prévoir la sécurité en amont (comme beaucoup de choses…). Mais c’est réellement beaucoup plus cher à traiter à postériori (comme un bug : plus c’est fait tard, plus ça coûte).
Ensuite, il y a un problème de formation. Autant des pilotes (direction, MOA…) que ceux qui réalisent (MOE) ou mettent en place / surveillent (Exploitation…). Pour une raison assez basique : on ne peut pas traiter ce que l’on ne connait pas.

 

HOW – Comment procéder ?

 

Dans un premier temps, le plus simple est de faire des formations ou des séances de sensibilisation (tout dépend du public cible). Le but, ici, est d’en parler, de faire prendre conscience, de faire un peu bouger les mentalités et surtout, que tout le monde se sente un peu concerné.

Exemple à la con sur la sécurité des postes de travail.
Il y a un « jeu » très simple : si un collègue part sans verrouiller sa session, il suffit d’envoyer un mail à l’équipe en disant que le collègue en question va rapporter les viennoiseries (pains ou chocolat ou chocolatines, c’est selon).
Ca s’appelle de l’usurpation d’identité. Ca permet d’avoir accès à tout plein de choses (applicatifs, documents…) avec les autorisations de la personne connectée.
En général, les personnes rentrent assez facilement dans le jeu et surtout, commencent à verrouiller leurs postes. C’est très con, mais ça veut dire que si quelqu’un s’introduit dans les locaux, aucun poste ne sera librement disponible.

Pour ce qui est des projets, il faut prévoir la sécurité dès l’expression du besoin pour pouvoir la décliner, comme un besoin ordinaire, tout au long des différentes phases (exigences, points de validation, tests…).
Et comme les audits de code qui peuvent être très bon pour la qualité, les audits de sécurité réguliers vont permettre de s’assurer que le besoin est satisfait (s’il y a une équipe de recetteurs « sécurité », c’est un plus).

En général, cette démarche s’inscrit dans une démarche générale d’entreprise. La sécurité n’est pas un sujet que l’on peut traiter par dessus la jambe (dans ce cas, mieux vaut ne rien faire, pour ce que ça va changer…).

Pour reprendre le tableau des failles, plus haut, si on les ordonne par occurrence, ça donne assez basiquement ceci :

  • Broken Authentication and Session Management
  • Cross Site Scripting (XSS)
  • Injection Flaws
  • Insecure [Cryptographic] Storage
  • Insecure Direct Object Reference
  • Cross Site Request Forgery (CSRF)
  • [Information Leakage and] Improper Error Handling
  • Failure to Restrict URL Access
  • Security Misconfiguration
  • Unvalidated Redirects and Forwards

C’est déjà un point de départ pour chercher et corriger les failles de sécurité.

Après, la sécurité, c’est aussi une « hygiène » à respecter.

Je reviendrais sur le sujet à plusieurs reprises.

 

Pour aller plus loin

 

Catégories :Développement, Sécurité
  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :