SRS Day. Sécurité Applicative

Transcription

1 SRS Day Sécurité Applicative Travail de sensibilisation sur les risques applicatifs, de recueil des solutions existantes et de présentation d une approche méthodologique d intégration de la sécurité dans le cycle de vie d une application. Dossier remis le vendredi 12 octobre 2012 Coach NGUYEN Vincent Auteurs BERENGUER Christophe BOLLIA Maxime BOVET Jules EYGASIER Luc GUIHÉNEUF Sabrine PIERRE Christophe SIMILOWSKI Paul SRS Day Sécurité applicative V.1

2 Sommaire 1. Remerciements Préambule Synthèse Décisionnelle Introduction Les risques applicatifs et leurs conséquences... 9 a. Les risques impactant la confidentialité... 9 b. Les risques impactant la disponibilité... 9 c. Les risques impactant l intégrité d. Les risques impactant la non-répudiation des preuves e. Les failles applicatives les plus exploitées f. Quelques exemples d utilisation i. L injection ii. Le Cross-Site Scripting iii. La violation de gestion d authentification et de session g. Des cas historiques d attaques applicatives État de l art des outils a. Outils d analyse de code i. Analyse statique manuelle Revue de code Méthode collaboratives ii. Analyse statique automatique b. Outils de développement i. Framework de gestion des accès et des autorisations ii. Framework de gestion de sessions iii. Framework de sécurisation des entrées/sorties iv. Framework de sécurisation des communications et des échanges v. Framework d auditabilité (logs) vi. Récapitulatif c. Outils de tests i. Scanneurs de vulnérabilités ii. Tests d intrusion d. Outils liés aux infrastructures i. Reverse Proxy ii. Firewalls applicatifs Présentation Différences avec un Firewall «classique» Fonctionnalités e. Normes de sécurité applicative i. IEEE P ii. ISO/CEI 27034: iii. GISSIP SRS Day Sécurité applicative V.1 Page 2

3 iv. BSIMM v. OWASP vi. OpenSAMM Les processus opérationnels des fonctions sécurité a. Processus du build b. Processus du run Méthode d intégration de la sécurité applicative dans un projet a. Gestion de la sécurité applicative dans un nouveau projet i. Phase de pré-étude ii. Phase de spécifications iii. Phase de conception iv. Phase de développement v. Phase de tests vi. Phase de déploiement vii. Phase de maintenance b. Intégration de la sécurité applicative dans un projet existant i. Contraintes et analyse contextuelle ii. Identification des principaux risques iii. Identification des solutions potentielles en fonction du contexte iv. Mise en place des correctifs c. La sécurité applicative dans le cas des progiciels et développements externalisés i. Aspects légaux et attribution des responsabilités ii. Renseignement, définition des besoins et validation des solutions iii. Recette sécurité et déploiement iv. Surveillance et maintenance Conclusion Glossaire Bibliographie SRS Day Sécurité applicative V.1 Page 3

4 Table des figures Figure 1 : OWASP Top Figure 2 : OWASP Top (modifié) Figure 3 : Logo du CWE Figure 4 : Logo de SVN Figure 5 : Logo de Git Figure 6 : Logo.NET Figure 7 : Logo Java Figure 8 : Fonctionnement du package JAAS Figure 9 : Logo d'apache Shiro Figure 10 : Logo de Sprint Security Figure 11 : Logo de SLF4j Figure 12 : Logo de Log4j Figure 13 : Architecture Logback-Audit Figure 14 : Logo de NLog Figure 15 : OWASP (Black Box Scanner Presentation) Figure 16 : Extrait de benchmark réalisé par Solucom pendant les tests d intrusions et audits Figure 17 : OWASP (Black Box Scanner Presentation) Figure 18 : Fonctionnement d'un Reverse Proxy Figure 19 : Logo de Bee Ware Figure 20 : Logo de DenyAll Figure 21 : Logo de BinarySec Figure 22 : Logo de Vordel Figure 23 : Logo de l'ieee Figure 24 : Logo de l'iso Figure 25 : Logo de l'anssi Figure 26 : Logo de BSIMM Figure 27 : Logo de l'owasp Figure 28 : Logo de l'opensamm Figure 29 : Présentation des activités de la méthodologie SAMM Figure 30 : Organisation des phases de Build et de Run dans un projet Figure 31 : Cycle générique du déploiement d'un correctif Figure 32 : Schéma de la maturité de la sécurité applicative des entreprises Figure 33 : Schéma de synthèse de l'intégration de la sécurité dans un nouveau projet Figure 34 : Schéma de synthèse de l'intégration de la sécurité dans un projet existant Figure 35 : Schéma de synthèse de l'intégration de la sécurité dans un projet externalisé SRS Day Sécurité applicative V.1 Page 4

5 1. Remerciements M. Vincent NGUYEN, notre coach et consultant chez Solucom Pour son accompagnement et la justesse de son esprit critique. M. Sébastien BOMBAL, responsable de la majeure SRS à EPITA et RSSI d Areva Pour sa confiance et ses directives. M. Gérôme BILLOIS, manager de la practice Sécurité & risk management de Solucom Pour son suivi du projet et la crédibilité qui nous fut témoignée. M. Laurent TREBULLE, directeur des relations entreprises à EPITA Pour sa gestion des formalités administratives. L ensemble des consultants de Solucom lecteurs de notre dossier Pour leurs revues de qualité et l approfondissement de nos réflexions. Le cabinet de conseil Solucom Pour son accueil et le partenariat ayant permis de sponsoriser cette édition du SRS DAY. L École Pour l Informatique et les Techniques Avancées Pour l occasion qui nous fût donnée de rédiger ce document. L ensemble des étudiants de la majeure SRS Pour le partage de leurs connaissances et de leurs idées. SRS Day Sécurité applicative V.1 Page 5

6 2. Préambule SRS Day 2012 Ce document a été réalisé dans le cadre du SRS Day 2012, un événement organisé chaque année par la spécialité SRS (Système, Réseau et Sécurité) de l EPITA, depuis Il s agit d un travail de recherche et de réflexion sur des sujets d actualité relatifs à la sécurité informatique, réalisé par les étudiants et encadré par des professionnels issus de chez Solucom, entreprise sponsorisant cette édition. EPITA Créée en 1984, l EPITA (École pour l Informatique et les Techniques Avancées) est une école d ingénieurs, membre du groupe IONIS depuis 1994, qui délivre un enseignement supérieur dans les technologies de l information et de la communication (TIC). Solucom Crée en 1990, Solucom est un cabinet indépendant de conseil en management et en système d information. Les clients de Solucom sont les entreprises et institutions leaders de leurs secteurs : 2/3 du CAC 40. Capable de mobiliser et de conjuguer les compétences de près de 1000 collaborateurs, leur mission consiste à «porter l innovation au cœur des métiers, à cibler et conduire les transformations créatrices de valeur, faire du système d information un véritable actif» au service de la stratégie de l entreprise. Solucom est coté sur NYSE Euronext (groupe mondial d entreprises de marchés financiers) et a obtenu la qualification entreprise innovante décernée par OSEO innovation (société anonyme chargée de l aide à l innovation en France). Pour plus d information, rendez-vous sur la revue en ligne de Solucom, ou directement sur SRS Day Sécurité applicative V.1 Page 6

7 3. Synthèse Décisionnelle La sécurité applicative est devenue un sujet récurrent et ancré dans le monde de la sécurité. En effet, Gartner estime que 75% des attaques ont ciblé des applications en D après Symantec, l impact financier des vols et pertes de données liés à ces attaques s élève, en 2011, à 2.6 millions d euros en moyenne par entreprise française, soit 16% de plus qu en Selon le Microsoft Developer Reasearch, 65% des développeurs estiment ne pas être qualifiés pour créer une application sécurisée, le déport des attaques des infrastructures vers les applications n est donc pas un hasard. La multiplication des interconnexions entre systèmes d informations est un facteur aggravant de ce phénomène. Le risque d une perte d un processus applicatif critique a permis aux entreprises de prendre conscience de l importance de la sécurité applicative. En effet, une atteinte à la disponibilité, à la confidentialité et/ou à l intégrité peut porter atteinte à la pérennité d une entreprise en menaçant son image de marque, son avantage concurrentiel ou son chiffre d affaires. La sécurité applicative ne se limite pas uniquement à l application, mais concerne aussi son utilisation et sa mise à disposition. Une démarche d intégration de la sécurité au cycle de vie des projets est donc nécessaire de bout en bout : depuis les spécifications et jusqu à l exploitation, en passant bien entendu par la phase cruciale du développement. De nombreuses normes et bonnes pratiques existent pour aider les entreprises et les administrations sur ce sujet. Dans ce contexte, des guides divers et outils variés ont été produits par les acteurs du marché pour aider à l amélioration du niveau de sécurité des applications. Cependant, ces solutions techniques et méthodes sont rarement mises en place efficacement, et très souvent destinées à des projets naissants. À l heure actuelle, les moyens dédiés à la sécurité applicative ne sont pas à la hauteur des enjeux. SRS Day Sécurité applicative V.1 Page 7

8 4. Introduction Au cours de ces dernières années, la sphère sécurité aura pu observer à ses dépens le déport des attaques depuis les infrastructures vers les applications. Aujourd hui, l actualité regorge d incidents, la prise de conscience est globale et le constat alarmant : l accroissement des risques applicatifs est mal maîtrisé au sein de systèmes d information de plus en plus ouverts et éclatés. Des études menées en 2009 par le groupe Gartner estiment qu environ 75% des attaques ciblent désormais les applications. D après Symantec, les vols et pertes de données liés à ces attaques ont coûté en moyenne 2.6 millions d euros aux entreprises françaises en 2011, ce qui représente une croissance de 16% par rapport à l année précédente. Selon Microsoft Developer Research, environ 65% des développeurs déclarent ne pas être qualifiés pour créer une application sécurisée. En conséquence les failles n en sont que plus nombreuses : 85% des applications Web sont par exemple vulnérables au cross-site scripting selon une étude de WhiteHat Security. Bien que toutes les entreprises aspirent à exploiter des applications sûres pour leurs activités, toutes ne sont pas à égalité en termes d enjeux métiers et de budget. La perte d un processus applicatif critique a des impacts en termes de disponibilité, de confidentialité et d intégrité pouvant porter atteinte à la pérennité d une entreprise en menaçant son image de marque, son avantage concurrentiel ou son chiffre d affaires. La majorité des applications ne sont pas exemptes de vulnérabilités, d'absence de contrôle ou de carence de conformité avec une réglementation. Mais les problèmes sont également étendus aux aspects stratégiques et organisationnels : l éloignement naturel entre les équipes responsables de la sécurité et celles du développement, la réticence au changement des collaborateurs, le manque de sensibilisation et de formation des équipes et les contraintes budgétaires. L objectif de la sécurité applicative est d adresser l'application, mais aussi son utilisation et sa mise à disposition. Une démarche d intégration de la sécurité au cycle de vie des projets est donc nécessaire de bout en bout : depuis la conception et jusqu à la phase de maintenance, en passant bien entendu par la phase cruciale du développement. Dans ce contexte, des guides divers et outils variés ont été produits par les acteurs du marché pour aider à l amélioration du niveau de sécurité des applications. Cependant, ces solutions techniques et méthodes sont rarement mises en place efficacement, et très souvent destinées à des projets naissants. Ce document a pour objectifs de sensibiliser sur les risques applicatifs, constituer un recueil des solutions techniques proposées en réponse aux différentes vulnérabilités couramment exploitées, de présenter les normes ainsi que les standards existants et de proposer une approche méthodologique d intégration de la sécurité dans le cycle de vie des applications. Les moyens dédiés à la sécurité applicative ne sont pas à la hauteur des enjeux. SRS Day Sécurité applicative V.1 Page 8

9 5. Les risques applicatifs et leurs conséquences Face à la croissance du nombre d applications, il est essentiel d analyser les risques qui peuvent être engendrés. En effet, une application est le fruit d un travail humain et il est difficile de garantir avec assurance qu elle ne présente aucune vulnérabilité. L association d une vulnérabilité avec un scénario de menace et des impacts caractérise un objet du risque. Ce risque peut porter sur la confidentialité, la disponibilité, l intégrité et la non-répudiation des preuves du système d information. Ces risques sont à mettre en perspective avec les impacts métiers que pourraient engendrer une attaque en termes d image, financier et réglementaire. Il est donc nécessaire pour un organisme de maîtriser ces risques applicatifs. Figure 1 : OWASP Top a. Les risques impactant la confidentialité La confidentialité du système d information, plus particulièrement des données, est un enjeu capital pour les entreprises. En effet, les bases de données des clients, les secrets industriels ou encore des données personnelles sont hébergés au sein d un système d information auquel peuvent avoir accès des applications. L atteinte à la confidentialité du SI peut aussi bien comporter un risque juridique que financier pour l entreprise. L exploitation d une faille applicative telle qu une injection SQL permettant le vol d information d une base de données est un exemple de risque applicatif pouvant porter atteinte à la confidentialité des données. b. Les risques impactant la disponibilité La disponibilité du système d information est un enjeu majeur dans la plupart des entreprises. Certaines applications métiers offrent de la valeur ajoutée aux entreprises et leur permettent ainsi d augmenter leur chiffre d affaires. La disponibilité des SRS Day Sécurité applicative V.1 Page 9

10 applications est intrinsèquement liée à la disponibilité des données et relève dès lors d un risque opérationnel à ne pas négliger. L exploitation d une faille par le biais d une configuration sécurité défaillante permettant un déni de service de l application est un exemple de risque applicatif portant atteinte à la disponibilité. c. Les risques impactant l intégrité L intégrité des ressources garantit qu elles n aient pas été altérées ou détruites. Ce critère de sécurité permet d acquérir un certain niveau de confiance concernant les ressources informatiques, dont les bases de données et les applications. L exploitation d une faille telle qu une injection SQL dans une application permettant de corrompre ou détruire le contenu d une base de données est un exemple de risque applicatif portant atteinte à l intégrité des données. d. Les risques impactant la non-répudiation des preuves La traçabilité permet d enregistrer toutes les actions liées à un système d information et donc de constituer une base de preuves. Un événement peut être imputé à un utilisateur et la non-répudiation est un critère de sécurité pouvant l empêcher de nier l action en question. L exploitation d une faille basée sur une violation de gestion d authentification et de session dans une application permettant à l attaquant d usurper l identité de la victime est un exemple de risque applicatif portant atteinte à la non-répudiation des preuves. e. Les failles applicatives les plus exploitées Les failles applicatives les plus exploitées selon l OWASP L OWASP (Projet de Sécurité des Applications Webs Ouvert) dresse régulièrement le classement des failles applicatives les plus exploitées. Le dernier classement que nous allons détailler dans cette partie date de Chacune des failles est notée en fonction de trois critères : le vecteur d attaque, la faille de sécurité et les impacts techniques. Ainsi, le risque applicatif est évalué en fonction de la facilité d exploitation de la faille, sa prédominance ou fréquence et sa facilité de détection. Ce n est qu après cette étape que les impacts techniques sont évalués. SRS Day Sécurité applicative V.1 Page 10

11 Figure 2 : OWASP Top (modifié) Abréviations Noms complets A1-Injection Injection A2-XSS Cross-site Scripting (XSS) A3-Authent Violation de Gestion d'authentification et de Session A4-DOR Références directes non sécurisées à un Objet A5-CSRF Falsification de requête inter-sites (CSRF) A6-Config Mauvaise configuration sécurité A7-Crypto Stockage cryptographique non sécurisé A8-Accès URL Manque de restriction d accès à un URL A9-Transport Protection insuffisante de la couche transport A10-Redirections Redirection et Renvois non validés Top 10 des vulnérabilités applicatives les plus critiques de l OWASP L OWASP dresse par ailleurs une liste des failles et des risques applicatifs à surveiller : Le Clickjacking ; Les accès concurrentiels ; Les dénis de service ; Les fuites d information et la mauvaise gestion des erreurs ; Le manque de mesures d anti-automatisation ; La gestion insuffisante des logs et de l imputabilité ; Le manque de systèmes de détection d intrusion et de réponse à intrusion ; L exécution de fichiers malicieux. Les failles applicatives les plus exploitées selon le CWE/SANS SRS Day Sécurité applicative V.1 Page 11

12 Figure 3 : Logo du CWE CWE (Common Weakness Enumeration) est une liste de vulnérabilités pouvant se trouver dans les applications. Le comité du CWE collabore régulièrement avec le SANS, un organisme américain visant à mutualiser les informations concernant la sécurité des systèmes d information, dans le but de publier le Top 25 des vulnérabilités applicatives les plus critiques. # ID Nom 1 CWE - 89 Injection SQL 2 CWE - 78 Injection de commande OS 3 CWE Dépassement de tampon («buffer overflow») 4 CWE - 79 Cross-site Scripting (XSS) 5 CWE Absence d authentification pour les fonctions critiques 6 CWE Absence d autorisation 7 CWE Utilisation d identifiants ou de mots de passe codés en dur 8 CWE Absence de chiffrement pour les données sensibles 9 CWE Aucune restriction au niveau du chargement de fichier avec un type dangereux 10 CWE Confiance en des données d entrées non fiables lors d une décision de sécurité 11 CWE Exécution avec des privilèges non nécessaires 12 CWE Cross-Site Request Forgery (CSRF) 13 CWE - 22 Path traversal 14 CWE Téléchargement de code sans contrôle d intégrité 15 CWE Autorisation incorrecte 16 CWE Inclusion de fonctionnalités provenant d une sphère de contrôle non fiable 17 CWE Attribution incorrecte des permissions pour des ressources critiques 18 CWE Utilisation d une fonction potentiellement dangereuse 19 CWE Utilisation d un algorithme de chiffrement cassé ou risqué 20 CWE Calcul incorrect de la taille d un tampon 21 CWE Restriction incorrecte des tentatives d authentification excessives 22 CWE Redirection d URL vers un site non fiable («Open redirect») 23 CWE «Format string» non contrôlé 24 CWE Débordement d entier («Integer Overflow») 25 CWE Utilisation d un hachage unidirectionnel sans sel Top 25 des vulnérabilités applicatives les plus critiques du CWE/SANS En outre la publication de ce classement, le CWE propose pour chacune de ces vulnérabilités des éléments afin de les prévenir et de les corriger. f. Quelques exemples d utilisation i. L injection SRS Day Sécurité applicative V.1 Page 12

13 Le but de cette attaque est multiple : corrompre une base de données ou un annuaire, récupérer des informations, ou exécuter du code à distance. Pour ce faire, l attaquant modifie les données attendues afin d altérer en conséquence la requête SQL, OS ou LDAP et d accéder à ses fins. Exemple de requête SQL vulnérable dans du code PHP : select * from accounts where id=.$get_[id]. L attaquant souhaite obtenir la liste de tous les comptes. Il va alors modifier le champ id de l URL avec la donnée suivante : or 1 = 1, comme dans l exemple ci-dessous : or 1 = 1 Ainsi, la requête exécutée sera la suivante : select * from accounts where id= or 1 = 1 Comme la condition «1 = 1» est toujours vraie, la requête listera toutes les informations contenues dans la table «accounts». Grâce aux informations collectées, l attaquant peut se connecter en usurpant l identité d un autre utilisateur, ne garantissant ainsi plus la non-répudiation des preuves. Cette attaque peut fortement impacter la confidentialité et l intégrité des données. ii. Le Cross-Site Scripting Le Cross-site Scripting, ou XSS, est une faille de sécurité web qui permet d injecter du code dans une page dans le but d effectuer des actions sur le navigateur d un utilisateur. Deux types de failles se distinguent : d une part, les XSS persistants correspondent à une injection de code dans une page, qui est stocké dans le serveur et qui est donc «permanente» ; d autre part, les XSS non persistants correspondent à une injection de code dans une page dynamique, effective uniquement au moment de l injection, et est donc «temporaire». Dans les deux cas, l attaque se porte au niveau du navigateur client et n impacte pas directement l infrastructure serveur, même dans le cas des XSS persistant. En effet, dans ce cas, le code injecté est uniquement stocké et n est pas exécuté au niveau du serveur. Pour exploiter un XSS non persistant, ce qui est le plus commun, l attaquant peut essayer de rediriger un utilisateur vers un site web malicieux et de récupérer des informations contenues dans le navigateur telles que les mots de passe ou autres SRS Day Sécurité applicative V.1 Page 13

14 données personnelles enregistrées. Pour ce faire, l attaquant envoie un ou utilise des liens malicieux afin d exécuter du code ou d exfiltrer des informations tels que les cookies ou les objets IE. Dans le cas d un XSS persistant, le code peut, par exemple, être injecté dans un message de forum. Exemple de chaîne de caractères comportant une faille XSS non persistant dans du code JavaScript : page+="<input name='creditcard' type= TEXT value='"+request.getparameter("cc")+"'>"; Cette chaîne de caractères permet d ajouter un champ dans un formulaire en HTML. L attaquant va alors pouvoir créer la requête suivante : gi-bin/cookie.cgi?foo='+document.cookie</script>' Ainsi, lorsque la victime va exécuter ce lien, ses informations de connexion telles que son session id seront envoyées à l attaquant. Ce dernier pourra ainsi voler la session de connexion de la victime et usurper son identité mais aussi procéder à une modification de la page pour tous dans le cas des XSS persistants. L impact en termes de confidentialité et sur la vie privée est considérable, tout comme l impact en termes d image du site légitime dans le cas de l exploitation d une faille XSS persistant par l attaquant. iii. La violation de gestion d authentification et de session Le but de cette attaque est d usurper l identité de la victime en lui subtilisant son jeton de session à travers par exemple la modification de données de type ASPSESSIONID ou JSESSIONID. Exemple de lien contenant un jeton de session : Ainsi, si l attaquant récupère ce lien ou l identifiant de session, il peut récupérer la session de la victime et accéder à ses données avec les privilèges de la victime. Les données sont ensuite volées ou corrompues. Cette attaque impacte fortement la confidentialité, l intégrité et la traçabilité. Comme l identité de la victime a été usurpée, la non-répudiation de la preuve est aussi remise en cause. g. Des cas historiques d attaques applicatives Que ce soit des pertes financières, une baisse de l image de l entreprise, une interruption de services ou autre, les attaques au niveau applicatif ne sont pas sans SRS Day Sécurité applicative V.1 Page 14

15 conséquences et présentent généralement un écart notable entre la simplicité de mise en œuvre et la criticité des impacts. Plusieurs cas d attaques en témoignent tels que le piratage de Citibank en 2011 qui se démarque par la facilité avec laquelle les pirates ont obtenu accès aux données des clients. En effet, il leur a suffi de s identifier et de modifier l identifiant du client (technique d altération de paramètre) dans l URL pour exploiter une faille de référence directe non sécurisée à un objet et accéder à n importe quel compte. En conséquences, les données de près de clients ont été compromises, cartes bancaires ont dû être réémises et 2.7 millions de dollars ont été détournés là où un travail de revue de code aurait permis de détecter la faille et de la corriger en utilisant une référence indirecte. Un autre exemple est l affaire d espionnage de Bercy détectée en 2011 au cours de laquelle 150 postes de travail du Ministère de l Economie, des Finances et de l Industrie ont été compromis. L attaque a été ciblée et fait preuve d une organisation minutieuse. En effet le vecteur d intrusion consistait d une pièce jointe PDF piégée envoyée à un destinataire bien choisi pour ensuite exploiter une faille logicielle. Bien que la technique soit courante, le souci réside dans le fait que les droits d administrateur aient été attribués à certaines applications qui n en avait pas besoin telles que les logiciels d impressions, ce qui a permis au code malveillant de se maintenir et agir. Par ailleurs, l attaque aurait pu être détectée en amont de la tentative d intrusion par le biais d un SIEM, dont ne disposait pas encore Bercy. Un manque de sensibilisation a également été noté. En conséquences, de nombreuses données sensibles ont été exfiltrées et près de ordinateurs ont dû être débranchés au cours du week-end. Malgré une politique de sécurité efficace, la mise en application de bonnes pratiques et l utilisation de nombreux dispositifs de sécurité, il suffit d une exception mineure pour engendrer des impacts majeurs. La sécurité doit donc se positionner sur chaque élément de la chaîne applicative, de l entrée utilisateur jusqu au socle technique de l application. SRS Day Sécurité applicative V.1 Page 15

16 6. État de l art des outils a. Outils d analyse de code Il est aujourd hui, comme présenté précédemment, essentiel de protéger son application de toutes les manières possibles. L une des façons d y parvenir est d effectuer une analyse du code et il existe de nombreux moyens le permettant. Ces moyens peuvent être aussi bien manuels qu automatiques et permettent de repérer les failles de sécurité mais également les erreurs de conception logicielle. i. Analyse statique manuelle L analyse statique de programme consiste à obtenir des informations sur le comportement d un programme sans réellement l exécuter. 1. Revue de code La revue de code consiste en une relecture intensive du code source d une application après son écriture. Cette relecture permet de porter un regard nouveau sur le code écrit par les développeurs et ainsi de corriger des erreurs de conception, notamment les erreurs pouvant entraîner des failles de sécurité. Il existe aujourd hui diverses techniques de revue de code : la relecture classique par un autre développeur. Chaque développeur, à la fin d un développement majeur, fait appel à un autre développeur afin que celuici relise et analyse le code écrit en indiquant potentiellement des axes d améliorations ou en corrigeant des erreurs minimes de conception ; la méthode dite du canard en plastique. Cette méthode a été publiée pour la première fois en 1999 dans l ouvrage de Andrew Hunt et David Thomas «The Pragmatic Programmer: From Journeyman to Master». Cette méthode consiste à expliquer le code source à un collègue, un passant ou simplement un objet inanimé (par exemple un canard en plastique), le simple fait d exprimer à voix haute ses pensées est censé permettre d aider à trouver les erreurs de programmation. 2. Méthode collaboratives La revue de code a pour but de vérifier le code après son écriture complète mais il existe également des méthodes permettant d analyser le code au cours de son écriture. Programmation en binôme (ou «Pair programming») Cette méthode fait partie des bonnes pratiques d une méthode agile appelée «Extreme programming». La programmation en binôme consiste, comme son nom SRS Day Sécurité applicative V.1 Page 16

17 l indique, à développer par équipe de deux afin d avoir plusieurs regards sur le code source au moment de son écriture. Le premier binôme, appelé pilote, a le clavier et écrit le code, tandis que le second binôme, appelé copilote, a pour rôle d aider le pilote en suggérant de nouvelles possibilités ou en décelant d éventuels problèmes. Les rôles de pilote et de copilote s échangent régulièrement lors des sessions de code afin qu aucune partie de la paire ne soit majoritaire dans les prises de décision. Cette méthode permet donc d éviter des erreurs basiques de conception mais ne dispense pas forcément le code source écrit d une revue. En effet, à forcer de programmer ensemble, la paire acquiert une même logique, les mêmes reflexes de développement et génère donc les mêmes erreurs. Systèmes de versions avancés Un système de gestion de versions est un logiciel permettant de stocker les différents fichiers composant un projet en conservant la chronologie de toutes les modifications qui ont été effectuées dessus. Les logiciels de gestion de versions actuels permettent donc de faciliter les revues de code au sein d un projet. Ils permettent effectivement de suivre pas à pas l évolution du projet en indiquant les différences entre deux révisions. Certains logiciels de gestion de versions permettent également de gérer les projets en utilisant un système de branche pour séparer la partie développement de la partie de test. En divisant ainsi le projet, il est plus pratique d effectuer les vérifications sur le code et d incorporer les nouvelles fonctionnalités après leurs validations. Voici quelques exemples de logiciels de gestion de version : Figure 4 : Logo de SVN SVN (Apache Subversion) est un logiciel de gestion de versions fonctionnant en mode centralisé, c'est-à-dire que toutes les sources sont situées sur un serveur central. Il permet notamment de : créer des révisions et de les comparer les unes aux autres ; versionner les métadonnées telles que les droits sur un fichier ; créer différentes branches pour un projet, permettant de faire plusieurs développements en parallèle. Malheureusement SVN ne permet pas de nommer les révisions rendant les opérations de changement de branche ou de révision plus compliquée (l utilisateur est obligé d entrer l identifiant unique de la révision désirée qui est une suite unique et aléatoire de caractères). SRS Day Sécurité applicative V.1 Page 17

18 Figure 5 : Logo de Git GIT est un logiciel de gestion de versions créé par Linus Torvalds (auteur du noyau Linux) et fonctionnant en mode décentralisé, c est-à-dire que chaque utilisateur possède sur son ordinateur un serveur lui permettant de faire des versions localement. Les serveurs locaux communiquent ensuite leurs différentes versions à un serveur central permettant ensuite d uniformiser l ensemble des versions. Ce système possède toutes les qualités de SVN mais ajoute également les éléments suivants : gestion décentralisée du versionnement ; possibilité de tagger les différentes versions afin de pouvoir les retrouver plus facilement ; possibilité d utiliser la commande pull request afin d indiquer aux personnes concernées qu une relecture de code est nécessaire. ii. Analyse statique automatique L analyse statique automatique de programme est aujourd hui très développée, à tel point qu elle est incorporée directement dans la quasi-totalité des environnements de développement. Elle permet notamment de détecter les erreurs de syntaxe, les variables non-initialisées et autres erreurs basiques de programmation. Voici quelques exemples d outils d analyse automatique : HP Fortify Static Code Analyzer HP Fortify Static Code Analyzer (SCA) est un outil développé et maintenu par HP permettant de repérer un grand nombre de vulnérabilités au sein d un programme. Cet outil classe ensuite les vulnérabilités par ordre de criticité et propose des solutions afin de pouvoir les corriger. Il permet de détecter plus de 480 types de vulnérabilités et ce dans 20 langages (C, C++, Java, PHP,.NET, etc.). HP Fortify SCA peut également être utilisé directement dans un éditeur tel qu Eclipse pour le Java. Google CodePro Analytix Google CodePro Analytix est un outil de test développé et maintenu par Google, pour les développeurs Java utilisant Eclipse, permettant tout comme HP Fortify Static Code Analyzer de vérifier statiquement le code afin d y trouver de potentielles vulnérabilités. Il permet également de générer des JUnits (tests unitaires pour le langage Java), et d analyser les ressemblances dans le code. IBM Security AppScan IBM Security AppScan est un outil de test créé par IBM et qui permet de détecter les vulnérabilités au sein d une application web. Il permet par exemple de tester les injections SQL, les dépassements de tampon, et dernièrement de repérer les failles XSS. RATS RATS (Rough Auditing Tool for Security) est un outil d analyse statique de code développé et maintenu par Secure Software. Il effectue une vérification des erreurs basiques de programmation (variables non-initialisées, dépassement de tampon, etc.), SRS Day Sécurité applicative V.1 Page 18

19 et fournit ensuite un compte-rendu détaillé des erreurs et des moyens d y remédier facilement. Flawfinder Flawfinder est un outil d analyse statique permettant d examiner un code pour d éventuelles failles de sécurité, notamment dans le domaine du dépassement de tampon. Pour ce faire, il repère les fonctions considérées comme dangereuses puis leur assigne un niveau de criticité. Cet outil se caractérise par sa rapidité d installation et d utilisation. Splint Splint (Secure Programming Lint) est une version moderne de «Lint» (un des premiers outils de vérification statique de code), qui permet de vérifier les vulnérabilités basiques d un programme (boucle infinie, variable non-initialisée, etc.). Il est également possible de réaliser des scripts d analyse de code automatique en utilisant des outils systèmes basiques. L écriture de script personnel permet d effectuer des vérifications plus précises et plus adaptées aux projets de l entreprise. b. Outils de développement Sécuriser toute son application est très long et souvent fastidieux. C est pourquoi il peut être intéressant d utiliser des frameworks proposant des mécanismes de sécurité déjà prêts ou alors des fonctionnalités souvent mal connues des plateformes de développement utilisées. Figure 6 : Logo.NET Figure 7 : Logo Java Bien qu un framework de sécurité ne garantisse pas forcément qu une application soit sécurisée, il est généralement utile et conseillé d en utiliser un. En effet, ceux-ci peuvent apporter des fonctionnalités très intéressantes telles que la gestion facilitée d une grande quantité d algorithmes de sécurité et permet en règle générale d accélérer le développement sécurisé d une application. i. Framework de gestion des accès et des autorisations Un des points le plus important, et souvent mal compris, à prendre en compte pour la sécurité d une application est la gestion des accès et des autorisations. Il faut pouvoir vérifier l identité d un utilisateur; c est à dire vérifier qu un utilisateur est bien ce qu il prétend être. Il faut aussi pouvoir dire à tout moment ce qu un utilisateur identifié a le droit de faire et surtout de ne pas faire (quel est son rôle). SRS Day Sécurité applicative V.1 Page 19

20 La gestion des accès et des autorisations est donc un élément critique de n importe quelle application et peut devenir rapidement très complexe. Plateformes de développement Java Depuis la version 1.4, Java met à disposition le package JAAS (Java Authentification and Authorization Service) pour gérer les problématiques d authentification et d autorisation. JAAS utilise un Subject pour désigner un utilisateur devant s authentifier. Le processus d authentification est réalisé par le LoginContext. C est la classe qui fait office de point d entrée quand JAAS est utilisé. Un LoginContext utilise un ou plusieurs LoginModules qui savent se connecter à un domaine de sécurité tel que LDAP ou une base de données. Le LoginContext utilise un fichier de configuration pour savoir quels LoginModules utiliser. Figure 8 : Fonctionnement du package JAAS Les callback handlers sont optionnels et permettent à une application d interagir avec le processus d authentification si nécessaire. Si l authentification est réussie, alors les LoginModules ont pour responsabilité d assigner un ou plusieurs Principals au Subject en cours. Ces objets Principals représentent le fait que le Subject est bien authentifié et permettent de gérer ses autorisations. Les autorisations sont ensuite gérées par un fichier de configuration où l on précise ce que chaque Principal a le droit de faire. JAAS permet donc de faire de l authentification et de l autorisation par rôle avec une possibilité de configuration très poussée et peut s adapter à n importe quel domaine de sécurité d une entreprise, ce qui en fait un outil extrêmement puissant..net Le framework.net permet d implémenter facilement une sécurité basée sur les rôles pour n importe quel type d application. Pour cela,.net met à disposition un accès à l utilisateur en cours, à travers une identité et un accès aux autorisations de l utilisateur via un principal. Il y a deux types de principal : un Window Principal et un Generic SRS Day Sécurité applicative V.1 Page 20

21 Principal. Un principal contient toujours une identité et s applique à un thread 1. Il est toutefois possible de définir une politique par défaut et donc d appliquer un principal à chaque fois qu un nouveau thread est créé. Le Window Principal fonctionne avec la gestion des utilisateurs du système d exploitation Windows ; un Window Principal relie donc un thread en cours d exécution à l utilisateur qui l a lancé. Le Generic Principal permet quant à lui de créer à la volée une identité et des rôles qui ne sont pas liés à Windows. Le Generic Principal n a pas vraiment d utilité et est donc délaissé pour un Windows Principal ou alors un principal personnalisé. Il est possible de créer son propre système d identification et d autorisation à partir d une base de données ou d un Kerberos grâce à un principal personnalisé. Pour cela, la création d une nouvelle identité se fait en implémentant l interface IIdentity et par la création d un principal en implémentant l interface IPrincipal. Dans tous les cas, pour utiliser la sécurité par rôle, il faut déclarer l utilisation d un principal pour le thread en cours en écrivant : AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal); Pour ensuite récupérer le principal d un thread ou en assigner un : MyPrincipalClass MyPrincipal = (MyPrincipalClass) Thread.CurrentPrincipal; Thread.CurrentPrincipal = MyPrincipal; Le framework.net propose tous les outils nécessaires pour gérer une sécurité par rôles avec les comptes Windows et expose un grand nombre d interfaces pour étendre cette sécurité à des domaines fortement utilisés en entreprise comme LDAP ou Kerberos. Frameworks externes En plus des possibilités offertes par les plateformes de développement, il existe de nombreux outils permettant d intégrer de la gestion des accès et des autorisations dans une application. Java Apache Shiro 1 En informatique, un thread correspond à l exécution d un ensemble d instructions. Aussi appelé fil d exécution ou tâche, il peut être apparenté à un processus mis à part que les threads d un même processus se partagent sa mémoire virtuelle. SRS Day Sécurité applicative V.1 Page 21

22 Figure 9 : Logo d'apache Shiro Shiro propose une solution d authentification et d autorisation puissante basée sur les Subjects, représentant l utilisateur qui exécute l application. L objet Subject est accessible partout dans le code et l authentification tient en un appel de méthode pour ne pas encombrer le code. Chaque Subject peut avoir plusieurs rôles ou permissions, une syntaxe puissante et intuitive permet de configurer très finement ces autorisations. Par ailleurs, Shiro propose plusieurs Realms qui sont en fait des Data Access Objects (DAO) pour pouvoir se connecter facilement à plusieurs domaines de sécurité comme LDAP, Active Directory et Kerberos, ce qui en fait un outil très apprécié. Autres points forts : gestion des autorisations directement dans le code ou avec des annotations ; compatibilité avec les programmes de cache pour une meilleure expérience utilisateur ; ne force pas à utiliser un type précis de données, tout peut être surchargé. Spring Security Figure 10 : Logo de Sprint Security Spring Security est un framework pour aider à l authentification et au contrôle des rôles dans les applications Java. Il peut en effet fonctionner avec des applications non Spring telles que Struts. Spring Security propose une configuration simple et poussée par XML qui permet de rapidement sécuriser une application en quelques lignes de configuration. Ses points forts : support d OpenID et de X.509 ; support de HTTPS ; support de l authentification HTTP BASIC et HTTP Digest ; support «out of the box» des domaines de sécurité LDAP, JDBC ou par fichier XML ; gestion du cache. Spring Security est donc fortement apprécié, plus particulièrement pour les applications web où celui-ci propose une multitude de fonctionnalités avancées par le biais d un système de configuration non intrusif. Son intégration ne nécessite donc que très peu, voire aucun changement dans le code. ii. Framework de gestion de sessions SRS Day Sécurité applicative V.1 Page 22

23 Dans les applications web, il est très souvent nécessaire d enregistrer des informations sur l utilisateur en cours au fur et à mesure que celui-ci parcourt l application. Du fait que le protocole HTTP soit non connecté, de nombreuses méthodes comme les cookies, l URL rewriting ou les champs cachés se sont développés pour garder une trace des actions de l utilisateur. Il existe cependant des solutions de plus haut niveau pour gérer ces problématiques de gestion de session. Plateformes de développement Java Java permet d identifier un utilisateur tout au long de l utilisation d une application web et de stocker des informations concernant l utilisateur grâce à HttpSession. HttpSession permet aux developpeurs de s abstraire de l utilisation des cookies en exposant plusieurs méthodes permettant de manipuler une session utilisateur comme une table de hachage reliée à un ID. Il est donc possible de stocker des objets Java correspondant à un utilisateur et de les récupérer à un autre moment dans l application. La création d une session se fait à partir d un objet HttpServletRequest, qui est la requête que l application reçoit, en appelant : HttpSession session = request.getsession(); La première fois que getsession() est appelée, une session est créée et celle-ci associe à l utilisateur un ID. Les autres fois, getsession() récupère l ID de l utilisateur et cherche l objet HttpSession associé à cet ID. HttpSession est donc un outil extrêmement simple d utilisation puisqu il abstrait beaucoup de choses dont le développeur n a plus à se soucier. C est aussi un outil puissant puisqu il permet de stocker des objets Java. Enfin, HttpSession marche avec HTTPS et permet donc un développement sécurisé..net.net propose par le biais de la classe HttpSessionState une gestion complète des sessions utilisateurs. Les sessions sont identifiées par une propriété appelée SessionID. Quand l état de session est activé pour une application ASP.NET, chaque requête dans l application est examinée de façon à trouver un champ SessionID envoyé par le client. Si aucun champ n est trouvé, alors ASP.NET crée une nouvelle session pour l utilisateur en cours et renvoie le SessionID au client par le biais d un cookie. Le fonctionnement est ensuite le même qu en Java, il est possible d utiliser la session de l utilisateur en appelant : HttpContext.Session[ MyProperty ] = MyObject dans le code ou alors d appeler directement l objet Session dans un objet Page. SRS Day Sécurité applicative V.1 Page 23

24 HttpSessionState est bien évidemment disponible avec HTTPS et il est même recommandé de l utiliser uniquement par l intermédiaire de communications chiffrées pour éviter le vol de session. C est donc un outil facile d utilisation et très apprécié pour la gestion des sessions utilisateurs. Frameworks externes Java Apache Shiro Shiro apporte la gestion de sessions même dans les applications non web. Les sessions de Shiro sont des POJO (Plain Old Java Object) et peuvent donc être utilisées très facilement dans un projet et stockées à peu près n importe où. Shiro apporte d autres avantages tels que : le partage de session entre plusieurs applications ; l ajout de «listeners» aux sessions pour par exemple gérer leurs expirations ; l implémentation de l interface HttpSession utilisée dans des applications web. iii. Framework de sécurisation des entrées/sorties Sécuriser les entrées des utilisateurs est un point crucial pour la sécurité d une application. Une grande partie des attaques comme les injections ou les failles XSS proviennent d entrées non sécurisées. Il existe donc pour cela des frameworks mis au point afin de contrer ces faiblesses. Frameworks externes OWASP AntiSamy AntiSamy est un framework Java et.net qui permet à partir d un fichier XML décrivant une politique de sécurité de nettoyer une chaîne de caractères HTML ou CSS. Il est simple à intégrer et à utiliser comme le montre l exemple ci-dessous : import org.owasp.validator.html.*; Policy policy = Policy.getInstance(POLICY_FILE_LOCATION); AntiSamy as = new AntiSamy(); CleanResults cr = as.scan(dirtyinput, policy); MyUserDAO.storeUserProfile(cr.getCleanHTML()); // custom function Cet outil est donc très apprécié lorsqu il s agit de faire face à de possibles codes HTML ou CSS malveillants. SRS Day Sécurité applicative V.1 Page 24

25 OWASP ESAPI ESAPI est un framework pour Java du groupe OWASP qui propose beaucoup de fonctionnalités avec, entre autres, les classes Encoder et PreparedString. PreparedString permet de créer des chaînes de caractères paramétrées de façon sûre et peut donc être utilisé pour créer toutes sortes de requêtes, par exemple SQL : PreparedString query = new PreparedString( "SELECT * FROM users WHERE name='?' AND password='?'", new OracleCodec() ); query.set( 1, request.getparameter( "name" ) ); query.set( 2, request.getparameter( "pass" ) ); stmt.execute( query.tostring() ); Cet exemple montre la construction d une requête SQL pour une base de données Oracle. Encoder permet lui d encoder ou de décoder des chaînes de caractères et gère HTML, JavaScript, MySQL, Oracle, les pourcentages (URL) et VBScript. Plateformes de développement Java iv. Framework de sécurisation des communications et des échanges Le package JSSE (Java Secure Socket Extension) de Java permet de mettre en place des communications sécurisées avec les protocoles SSL et TLS et inclut des fonctionnalités pour faire du chiffrement de données et de la vérification d intégrité de messages. Il est donc possible de sécuriser une connexion entre un serveur et un client qui utilisent le protocole TCP/IP. JSSE supporte les versions 2.0 ou 3.0 de SSL et la version 1.0 de TLS. Les algorithmes de sécurité gérés sont : RSA bits et plus ; RC4-128 bits ; DES - 64 bits ; Triple DES bits ; AES - 128/256 bits ; Diffie-Hellman - 512/1024 bits ; DSA bits. Ces algorithmes sont en mesure de répondre à la majorité des besoins d une application sauf cas particuliers ; en effet, ceux-ci sont tous utilisés de nos jours à l exception de DES à 64 bits qui n est plus conseillé. JSSE abstrait donc les algorithmes de sécurité ainsi que les mécanismes dit de «handshaking» qui sont complexes et minimise donc les risques de créer des vulnérabilités de sécurité dans une application. SRS Day Sécurité applicative V.1 Page 25

26 JSSE est disponible sous la forme d une API et fournit une implémentation par défaut. Il est possible d étendre cette dernière pour répondre à certains besoins précis que les développeurs pourraient avoir. Les fonctionnalités offertes par ce package sont très complètes et suffiront en règle générale à tout type d application. Pour gérer la sécurité des données, JAVA offre le package JCA (Java Cryptographic Architecture) sur lequel repose JSSE. JCA permet de faire de la signature numérique, de créer et valider des certificats, du chiffrement et du hachage de données, de la génération et du stockage de clés ainsi que de la génération de nombres aléatoires. Comme JSSE, JCA propose des classes déjà prêtes ou encore des API pour pouvoir étendre le comportement des classes de base et pouvoir être intégré au mieux dans n importe quel projet. Enfin, JCA supporte les mêmes algorithmes que JSSE. Le couple JCA/JSSE permet finalement de chiffrer ses données et d utiliser des canaux d échange sécurisés. Il suffira à sécuriser pratiquement n importe quelle application et constitue un outil puissant disponible depuis la version 1.4 de Java..NET L espace de nom System.Security.Cryptography du framework.net contient une multitude de classes permettant de faire du chiffrement par clés privées et clés publiques, de la signature numérique, du hachage de données et de la génération de nombres aléatoires. Il supporte les algorithmes suivants : AES ; DES ; SHA-1/256/384/512 ; RC2 ; Rijindael ; Triple DES ; DSA ; RSA ; Diffie-Hellman ; MD5. La signature numérique ainsi que la génération de nombres aléatoires sont disponibles à partir de la version 3.5 du framework. Le chiffrement et le hachage de données fonctionnent avec la version 1.1 et plus. L espace de nom System.Net.Security apporte quant à lui la classe SslStream depuis la version 2.0 du framework. Cette classe permet d ouvrir un canal d échange SSL entre un serveur et un client. L authentification se fait en utilisant des certificats X509. Frameworks externes Java Apache Shiro SRS Day Sécurité applicative V.1 Page 26

27 Shiro propose un module de cryptographie qui permet de chiffrer des données ainsi que de les hacher. Il s appuie sur JCE qui fait partie du package JCA. Le but de ce module est de simplifier l utilisation des classes mises à disposition dans JAVA en abstrayant par exemple toutes les méthodes Factory. De plus, Shiro met ici encore un point d honneur à n utiliser que des POJO (Plain Old Java Object) pour une grande facilité d intégration dans un projet. Les algorithmes de chiffrement et de hachage les plus réputés sont mis à disposition et Shiro facilite par ailleurs la gestion du sel 2 et du hachage consécutif pour, par exemple, gérer plus aisément la protection des mots de passe. v. Framework d auditabilité (logs) Il est très important de pouvoir enregistrer les actions et les événements qui interviennent durant l'utilisation d'une application afin de garder des traces exploitables pour d'éventuels analyses ou audits. Il existe certains frameworks permettant de rapidement mettre en place de tels systèmes. Frameworks externes Java SLF4j Figure 11 : Logo de SLF4j SLF4j consiste en une API permettant d'harmoniser les appels de log dans du code java quel que soit l'implémentation choisie. Il permet d'attacher des variables de log à un thread telles que le login d'un utilisateur, ce qui permet de suivre le déroulement d'un objet au sein d'une application même dans des logs entièrement entrelacés. Ce framework permet également de tagger les logs suivant un marqueur, qui définira une suite d'actions à effectuer. Il est par exemple possible avec ce système de séparer des logs classiques de logs confidentiels, ces derniers seront chiffrés avant d'être écrits. Apache Log4j 2 Le salage est une technique de renforcement de la sécurité qui consiste à concaténer une chaîne de caractères pseudo-aléatoire à l information avant le hachage. Ex : l identifiant de l utilisateur est haché à l aide de la fonction SHA-1, puis concaténé au mot de passe lui-même haché à l aide de la fonction MD5. SRS Day Sécurité applicative V.1 Page 27

28 Figure 12 : Logo de Log4j Log4j est un framework de la famille Apache qui apporte des fonctionnalités pour intégrer des logs dans n'importe quelle application java. Ses avantages sont : système de plugin permettant d'étendre toutes les parties du framework ; système de filtres permettant de déterminer si et/ou comment un message de log devrait apparaître suivant un certain contexte. Logback et Logback-Audit Logback se désigne comme étant le successeur de Log4j et permet d en réaliser les mêmes opérations. L un des avantages principaux de Logback est son module Logback-Audit qui sépare les logs «traditionnels» (messages techniques destinés le plus souvent au debug) des logs d audits (contenant des messages utiles pour le business). Logback-Audit fournit un serveur recevant ces logs d audits provenant des applications pour ensuite les stocker dans des bases de données. Figure 13 : Architecture Logback-Audit.NET NLog SRS Day Sécurité applicative V.1 Page 28

29 Figure 14 : Logo de NLog NLog est sûrement l un des frameworks aidant à gérer les logs le plus complet pour l environnement.net. Il permet de prendre en charge comme support : un ou plusieurs fichiers simultanément ; des bases de données supportées par.net ; le réseau en utilisant comme protocoles UDP, TCP, SOAP et MSMQ ; les s ; et beaucoup d autres tels que la console, etc. La configuration se fait à l aide d un fichier XML et permet de gérer tout ce qu un framework de log devrait apporter tel que le type de format de sortie (texte brut, CSV, XML, etc.), ainsi que des filtres pour appliquer des transformations aux logs suivant un certain contexte. Il est important de noter que depuis juillet NLog ne reçoit plus de mise à jour par son auteur, le projet sera peut-être repris par d autres personnes. Apache Log4net Log4net est un framework appartenant à la famille Apache. Il gère les mêmes supports que NLog et propose à peu de choses près les mêmes fonctionnalités. Un des atouts de Log4net est qu il repose sur la même architecture que Log4j qui est prouvée robuste, en développement depuis C est donc un framework sûr qui allie rapidité et flexibilité. vi. Récapitulatif Java et.net fournissent déjà beaucoup d outils pour aider les développeurs à gérer les problématiques d accès et d autorisations, de gestion de sessions et de sécurisation des communications et des échanges. Il existe tout de même quelques frameworks permettant de faciliter et raccourcir les phases de développement qui méritent d être mentionnés et utilisés. Du côté de la sécurisation des entrées/sorties et de l auditabilité d une application, il faudra plutôt se tourner vers un framework pour aider le développement, les plateformes.net et Java n offrant pas de solutions clés en main. Apache Log4net.NET Accès et autorisations Sessions Sécurisation des entrées/sorties Sécurisation des communications et des échanges Auditabilité NLog.NET Apache Shiro Spring Security OWASP ESAPI Java Java Java SRS Day Sécurité applicative V.1 Page 29

30 Apache Log4j Java SLF4j Java Logback Java OWASP AntiSamy.NET/ Java c. Outils de tests Présentation générale i. Scanneurs de vulnérabilités Le milieu applicatif regorge de méthodes et de bonnes pratiques afin de produire du code fiable et fonctionnel. Parfois même, les développeurs ont à leur disposition des outils ou frameworks permettant de les aider dans la production d applications sécurisées. Mais, comme dans tout domaine, les phases de tests sont onéreuses pour les entreprises qui ne leurs accordent souvent pas assez de temps. C est pour répondre au besoin de tester et sécuriser les applications que les «scanneurs de vulnérabilités» ont vu le jour. Le but de ces outils est de permettre aux entreprises d automatiser les tests de sécurité sur leurs produits. Grâce aux scanneurs, la phase de test d une application requiert donc beaucoup moins d intervention de la part des employés, qui ont donc plus de temps à consacrer à la production. Pour s assurer de la sécurité d une application, la famille de tests opérés par le scanneur est dite «test boite noire». Cela signifie que le scanneur devra effectuer ses tests en «aveugle», sans aucun accès au code source, comme le ferait un utilisateur normal ou un éventuel attaquant. Cela permet donc d effectuer un grand nombre de tests automatiquement et efficacement en utilisant les failles les plus exploitées dans le milieu informatique. Selon l objet du test, différents types de scanneurs existent à la fois sur le marché et dans le monde open-source. Ainsi, les besoins peuvent varier selon les utilisateurs. Certains voudront, par exemple, focaliser leurs tests sur leur infrastructure et s orienteront donc sur des scanneurs permettant de tester les vulnérabilités liées aux équipements qu ils possèdent. D autres encore rencontreront le besoin de tester leurs bases de données ou leurs ERP (Entreprise Resource Planning). Pour répondre à ces différents besoins, on peut donc catégoriser les scanneurs afin de pouvoir choisir celui qui correspond aux tests que nous voulons effectuer. Les différentes catégories de scanneurs sont : scanneurs de réseau ; scanneurs de base de données ; scanneurs de progiciels type ERP ; scanneurs d applications/web Applications. SRS Day Sécurité applicative V.1 Page 30

31 Les scanneurs de réseau visent à tester essentiellement des vulnérabilités liées à la fois aux protocoles réseaux utilisés, mais aussi aux équipements critiques d une infrastructure tels que des routeurs. Ils intègrent bien souvent d autres outils tels que des scanneurs de ports. Ce type de scanneur est donc plutôt utilisé dans le but de tester une architecture réseau ainsi que ses équipements. On ne l utilisera donc pas pour rechercher des vulnérabilités liées à une application en développement, ou seulement en complément d un scanneur dédié. En général, les bases de données ainsi que les logiciels ERP sont des ressources importantes pour une entreprise, c est pourquoi il existe aussi un type de scanneur dédié à la détection de failles dans ces deux domaines. Mais là encore, ce sont des scanneurs assez pointus dans leurs domaines respectifs et ne seront utilisés que peu ou partiellement dans le cadre d un test d application en développement. La dernière catégorie de scanneurs : les scanneurs d applications sont ceux auxquels nous allons nous intéresser particulièrement. Nous allons donc commencer par énumérer les différentes catégories de vulnérabilités que traite ce type de scanneur. Nous essaierons ensuite d estimer la répartition des tests du scanneur selon les catégories établies précédemment. Puis nous confronterons les données établies avec les vulnérabilités pouvant être rencontrées actuellement. Fonctionnalités Les scanneurs d applications Web possèdent en général des palettes de tests, organisées en fonction des failles les plus connues ou exploitées par les attaquants. Il est donc normal, même si plusieurs scanneurs existent sur le marché, de pouvoir catégoriser les types de vulnérabilités que tous ces produits testent sur les applications. Nous allons énumérer les différentes catégories de tests que les scanneurs opèrent en citant quelques exemples de vulnérabilités liées à ces catégories : Cross Site Scripting (XSS) ; SQL injections ; Cross channel scripting : o arbitrary file upload ; o remote file inclusion ; o OS command Injection ; Session management : o bypass authentification ; o session fixation and prediction ; Cross-site Request Forgery (CSRF) ; Configurations : o self signed certificates ; Information leakage : o temporary file access ; o fingerprinting. Nous pouvons constater que ces vulnérabilités représentent des classiques en matière de sécurité dans le milieu applicatif. Il est donc normal que les scanneurs se focalisent SRS Day Sécurité applicative V.1 Page 31

32 sur ces vulnérabilités afin de pouvoir tester un maximum d applications Web. En effet, celles-ci pourraient se révéler de véritables nids pour de telles vulnérabilités et il est primordial de tester ces failles connues. De plus, la connaissance de ce type de vulnérabilité est telle qu il est facile d organiser des suites de tests automatiques permettant de confirmer ou écarter la présence de celles-ci. Nous allons à présent observer la répartition du nombre de tests par catégorie. Les chiffres utilisés dans les prochains graphiques proviennent d une présentation de l OWASP sur les scanneurs de vulnérabilités. Ils ont été obtenus en agrégeant les caractéristiques de différents scanneurs, leaders dans leurs domaines respectifs : Rapid7 ; Qualys ; N-Stalker ; McAfee ; IBM ; HP ; Cenzic ; Acunetix. Ce qui donne la répartition suivante : Figure 15 : OWASP (Black Box Scanner Presentation) Ces résultats peuvent paraître étonnants au premier abord de par le nombre de tests réalisés en rapport avec la fuite d information, mais ce chiffre s explique par deux SRS Day Sécurité applicative V.1 Page 32

33 raisons : tout d abord, la collecte d information est une étape importante lors de l attaque d un site web ou d une application. C est en effet en ayant une bonne connaissance des technologies mises en œuvre que l attaquant sera en mesure de trouver les vulnérabilités connues et disponibles en fonction de sa cible. Il est donc important lors du test d une application de connaître exactement les informations que l attaquant aura en main lors d une éventuelle attaque. La seconde raison est quant à elle simple : les tests afin d obtenir le plus d information possible doivent être nombreux. Même s ils sont plus faciles à concevoir que les tests pour les autres catégories de vulnérabilités, il en résulte un plus grand nombre au final. Comparons maintenant ces chiffres avec la répartition des plus grandes vulnérabilités détectées entre 2010 et 2012 : Figure 16 : Extrait de benchmark réalisé par Solucom pendant les tests d intrusions et audits Nous retrouvons bel et bien les plus grands risques réels dans les palettes de tests de nos scanneurs. D autre part, nous constatons que les failles de type XSS comptent pour autant dans les palettes de tests que dans les chiffres réels de 2011, ce qui rassure quant à la fiabilité des tests pratiqués. Le prochain graphique reprend l étude d OWASP sur les scanneurs de vulnérabilités. Il décrit les taux de détections des scanneurs par rapport à certaines failles connues. Les précédents scanneurs cités ont été testés sur une application Web conçue spécialement pour l occasion afin de pouvoir tester les limites de tels outils et ainsi connaître ce que nous pouvons réellement attendre à l heure actuelle de ceux-ci. SRS Day Sécurité applicative V.1 Page 33

34 Figure 17 : OWASP (Black Box Scanner Presentation) Nous pouvons ainsi constater que la plupart des vulnérabilités de type XSS simples sont détectés. La sensibilisation à l existence de telles failles permet donc aux concepteurs d applications de se prémunir contre les attaques d outils automatiques ou la majorité des attaquants non-expérimentés. A l inverse, le taux de détection des vulnérabilités de type XSS avancées chute drastiquement. Les erreurs communes de configuration ainsi que la fuite d informations ne sont quant à elles couvertes que partiellement. Par rapport aux risques encourus, le fait que la détection de failles de type XSS soit mis en avant dans ces résultats est rassurant. Le taux de détection des scanneurs est cependant bien en dessous de la moitié des vulnérabilités réellement présentes. En conclusion, même si l utilisation de tels outils s avère fortement utile pour tester la robustesse d une application, il ne faut surtout pas s appuyer entièrement sur les résultats fourni par le scanneur. En effet, celui-ci permettra de se prémunir contre l attaque d outils automatiques utilisant les mêmes technologies de détection, mais absolument pas contre une attaque ciblée de professionnels. Le constat de ces dernières années est globalement une expertise grandissante du milieu cybercriminel, il est donc important de devoir réaliser des tests dirigés par l homme, plus particulièrement des professionnels, plutôt que se reposer entièrement sur le rapport des scanneurs de vulnérabilités. Le tout afin de pouvoir fournir une sécurité la plus optimale possible, en fonction bien sûr du domaine pour lequel est destiné l application ainsi que du budget alloué à la sécurité. SRS Day Sécurité applicative V.1 Page 34

35 ii. Tests d intrusion Face à la nécessité de sécuriser les applications, beaucoup d outils ont vu le jour. Nous avons étudié précédemment les outils automatiques afin de tester une application et s assurer de sa sécurité. Nous avons néanmoins remarqué que même si ces outils pouvaient s avérer utiles afin de débusquer quelques problèmes parmi les plus couramment répandus, ceux-ci ne permettaient pas d assurer une sécurité suffisante dans le cas d applications sensibles. D autre part, face à la sophistication des attaques ainsi que l expertise qui se dégage peu à peu du côté cybercriminel, il est essentiel de posséder des méthodes de tests avancées pour garantir qu une application est sécurisée. A l heure actuelle, l homme reste donc le mieux placé afin de tester la sécurité, c est pour cela que les «tests d intrusion», plus communément appelés «Pentesting», ont vu le jour. Les tests d intrusion sont en réalité la simple simulation d une attaque, le plus souvent par un élément extérieur au développement, afin de pouvoir se faire une bonne idée du niveau de robustesse de l application. Ces tests sont donc le plus souvent réalisés par des entreprises spécialisées, ce qui tend à refléter le niveau d une attaque en situation réelle et ciblée puisque des experts sont impliqués dans les deux cas. Le «Pentesting» se différencie d un simple audit de sécurité de par le fait que l attaquant essaie bel et bien de prouver qu une vulnérabilité est exploitable afin d en déterminer le risque encouru ainsi que l impact pouvant être engendré par une réelle attaque. L audit n est censé quant à lui qu évaluer les risques potentiels, sans vraiment chercher à exploiter les vulnérabilités. En ce sens, les tests d intrusions sont de forts atouts car ils permettent notamment de prouver la faisabilité d une exploitation. Pour mener à bien ces tests, plusieurs méthodes existent suivant le niveau de sécurité que l on souhaite obtenir ainsi que la quantité de données que pourrait posséder un éventuel attaquant afin de préparer son attaque. On peut en général séparer les tests d intrusion en 3 catégories : Black Box ; Grey Box ; White Box. Les tests d intrusion de type «Black Box» tendent à démontrer la sécurité de l application pour une attaque sans aucune information quant à la manière dont elle a été réalisée. L auditeur ne possède aucune information autre que l adresse de l application sur laquelle il doit effectuer ses tests, c est donc à lui d effectuer toutes les étapes par lesquelles un attaquant devrait passer : débutant par la prise d information SRS Day Sécurité applicative V.1 Page 35

36 et dans les pire cas, l exploitation d une faille. Ce type de test donne une assez bonne représentation du niveau de sécurité de l application la majeure partie du temps. La catégorie «Grey Box» est associée à la livraison de comptes applicatifs à privilèges distincts. L objectif étant généralement de tester les cas d escalades de privilèges et/ou de cloisonnement des comptes et espaces utilisateurs. Les tests de type «White Box» sont pour leurs parts, les tests les plus poussés. En effet, pour réaliser ceux-ci, l auditeur est censé posséder toutes les informations relatives à l application qu il teste et même à son code source. Parfois même, un accès au backend de l application peut être fournit. Le plus souvent, le testeur s orientera donc vers l étude du code source de l application afin de débusquer d éventuelles failles, qu il pourra exploiter par la suite afin de démontrer leur faisabilité. Des approches mixtes sont souvent employées afin d assurer un maximum de sécurité. Deux testeurs, l un testant suivant une méthodologie de type White Box, et un autre soumis à un audit de type Black Box, testent l application en parallèle. Il n est pas rare que ces deux types de tests soient effectués par la même personne. Cette pratique permet de nuancer certains problèmes afin de pouvoir juger ce qui est réellement critique ainsi que le risque résiduel que l application peut se permettre de conserver. Les tests d intrusion sont à l heure actuelle la meilleure manière de se rendre compte de la sécurité d une application puisque toutes les étapes d une attaque peuvent être rejouées. d. Outils liés aux infrastructures i. Reverse Proxy Aujourd hui, afin de protéger les applications, il est nécessaire de contrôler les requêtes transmises aux serveurs applicatifs et les réponses que ceux-ci renvoient, pour se faire on peut utiliser un reverse proxy. Le reverse proxy permet de faire la jonction entre l extérieur (Internet dans la plupart des cas) et les serveurs internes. Le reverse proxy transmet alors de manière indirecte toutes les requêtes qui leurs sont adressées. SRS Day Sécurité applicative V.1 Page 36

37 Figure 18 : Fonctionnement d'un Reverse Proxy Chaque requête effectuée au serveur web transite donc par le reverse proxy qui la traite avant de la transmettre réellement au destinataire initial. Le serveur web traite ensuite la requête et renvoie une réponse directement au reverse proxy qui l analyse. Si la réponse est correcte, elle est renvoyée au demandeur par le reverse proxy, dans le cas contraire le reverse proxy peut modifier la réponse. Afin de traiter les requêtes et les réponses le reverse proxy utilise plusieurs applications dont : la réécriture d URL ; le chiffrement SSL ; la répartition de charge ; l utilisation du cache ; la compression des contenus ; l analyse du contenu des échanges. Réécriture d URL La réécriture d URL est une technique qui permet, comme son nom l indique, de réécrire une URL à la volée. Le but de cette technique est de pouvoir contrôler les demandes envoyées par le client. En effet, si le client essaye d envoyer une requête corrompue (en tentant une injection SQL par exemple) alors le mécanisme de réécriture d URL permettra de modifier la requête avant que celle-ci arrive au serveur, ce dernier recevra donc une requête sans risque de corruption de ses données. La réécriture d URL ne permet pas seulement de faire du filtrage, il permet aussi de faire du masquage et par exemple de dissimuler l architecture interne d une application. Chiffrement SSL Le chiffrement SSL consiste à protéger les échanges entre le serveur et le client en utilisant le dit protocole SSL. Le reverse proxy se charge de lui-même de chiffrer les échanges afin de les sécuriser, ce qui a pour avantage d être totalement transparent pour le client. Le protocole SSL (Secure Sockets Layer) devenu TLS (Transport Layer Security) en 2001 permet d effectuer les points suivants : authentifier le serveur cible afin d être sûr que les requêtes ne vont pas être interceptées par un tiers ; SRS Day Sécurité applicative V.1 Page 37

38 sécuriser les échanges de données en les chiffrant via un algorithme asymétrique et un algorithme symétrique ; vérifier la conformité des données à leurs réceptions. Répartition de charge L un des problèmes récurrent dans une application Web est la mauvaise répartition de la charge sur les différents serveurs applicatifs, pouvant augmenter significativement les temps de réponse aux requêtes. Afin de résoudre ce problème, il faut utiliser les mécanismes de répartition de charge qui permettent d adapter l utilisation des ressources en fonction de la demande. Le principe de la répartition de charge est simple, il consiste à rediriger les nouvelles requêtes vers les serveurs les moins utilisés. Gestion du cache et compression Le reverse proxy peut également réduire les risques d attaque par déni de service (DoS) en utilisant la mise en cache et la compression des requêtes et de leurs contenu. Effectivement le reverse proxy peut stocker certaines images/pages web en cache local afin d y avoir accès plus rapidement et éviter un accès au serveur web répété. La compression de contenu, quant à elle, permet de réduire le volume de données échangé entre le serveur interne et le reverse proxy. ii. Firewalls applicatifs 1. Présentation Comme nous l avons vu précédemment, le déport des attaques vers les applications au lieu des infrastructures liées à leur fonctionnement est devenu un fait courant dans le monde de la sécurité. Aussi, bien que les frameworks utilisés aident de mieux en mieux à maintenir un niveau de sécurité convenable, la majorité des problèmes résident au niveau du code propre à l application elle-même. Afin d assurer une sécurité optimale, le niveau d expertise requis ainsi que les divers phases de tests sont le plus souvent hors du domaine de compétence des développeurs impliqués dans la réalisation des d applications. Il parait donc rassurant que des solutions soient créées spécialement pour combler le manque d expérience et assurer un bon fonctionnement des applications existantes. Les firewalls applicatifs (WAF) répondent donc à ce besoin de déporter de l application même les éventuels problèmes de sécurité. Plusieurs formes de firewalls applicatifs existent comme nous le détaillerons par la suite. Néanmoins, l objectif commun de ces différentes approches reste la vérification des entrées/sorties liées à une application en vue d un éventuel blocage si le flux n est pas légitime. SRS Day Sécurité applicative V.1 Page 38

39 Il est donc important que toutes les solutions présentées possèdent un certain nombre d exigences. Parmi les différents critères publiés par l OWASP, certains sont essentiels à souligner. Ainsi il faut qu un firewall applicatif puisse répondre aux contraintes suivantes : une protection contre le top 10 des vulnérabilités publiées par OWASP ; un taux de faux positif relativement faible. En effet, il faudrait que le firewall ne bloque en aucun cas une requête légitime ; une personnalisation des règles caractérisant les flux facile d utilisation et souple ; des performances assez hautes en termes de temps de réponse : il ne faut pas que la traversée du firewall par un flux se ressente énormément et soit handicapant du côté utilisateur ; un système d alerte, de reporting, ainsi que des logs et des outils facilitant les analyses forensics après sinistre ; des protections contre le bruteforce. Voici quelques exemples d éditeurs de solution de Firewalls Applicatifs : Figure 19 : Logo de Bee Ware Figure 20 : Logo de DenyAll Figure 21 : Logo de BinarySec Figure 22 : Logo de Vordel 2. Différences avec un Firewall «classique» La différence fondamentale entre un firewall classique et un firewall applicatif réside dans le fait que le premier se charge de traiter la forme des flux alors que l autre en inspecte le contenu. Ainsi, on peut affirmer qu un firewall classique se contente d analyser l'enveloppe seule, alors qu un firewall applicatif étudie plus en profondeur le message qu elle transporte. Les règles permettant de différencier ce qui est légitime de ce qui ne l est pas sont donc réellement différentes. Un firewall classique portera une attention à ce qui caractérise le flux en lui-même : ports utilisés ; listes d adresses IP blanches ou noires ; protocoles utilisés. SRS Day Sécurité applicative V.1 Page 39

40 Au contraire, comme nous l avons vu précédemment, le firewall applicatif analysera le contenu du flux pour par exemple essayer de déceler dans un flux XML une tentative d attaque. 3. Fonctionnalités Protections contre les exploitations logicielles En suivant une liste de règles propre à une application et couplé à un moteur de détection de signatures malveillantes et d actions utilisateurs en temps réel, les firewalls applicatifs peuvent bloquer les attaques contre les applications comme : les shellcodes et buffer overflow : beaucoup ont une signature reconnaissable et bien que possiblement chiffrés, ils ne correspondent pas aux données attendues et spécifiées dans les règles du firewall, que ce soit au niveau de la taille ou du contenu ; le fuzzing. Protections contre les attaques web Les firewalls applicatifs répondent au besoin de combler un niveau de sécurité généralement faible du côté de l application. Qui plus est, de plus en plus d applications auparavant cantonnées à l interne, s ouvrent à internet. La majorité des firewalls applicatifs permettent donc de contrer les attaques de type web comme : les vols de sessions ; les attaques XSS ; les découvertes d URL non bloquées ; l empoisonnement de cookie ; les attaques DDoS. Protections contre les injections Les injections sont généralement faciles à réaliser et ont un impact sévère. C est d ailleurs pour cela que les injections sont les attaques les plus courantes et sont numéro un des risques pour les applications web selon l OWASP. Les firewalls applicatifs font pour la plupart très attention à celles-ci et permettent de bloquer entre autre : les injections SQL ; les injections LDAP ; les attaques par Null Byte : Couper une chaîne de caractères à l aide d un null byte afin d enlever une partie de cette chaîne. Il est possible de réaliser ensuite des LFI (Local File Inclusion) par exemple ; injections CRLF ; injections SSI ; injections XQuery/XPath : Lorsque des entrées utilisateurs sont utilisées pour construire une requête XPath ou XQuery pour des données XML. Protections contre les corruptions de flux XML Un firewall applicatif peut protéger les flux XML d une entreprise en employant plusieurs méthodes : terminer le trafic SSL/TLS : il faut pouvoir inspecter ce qui passe sur le réseau, ce qui est un point très important pour que le firewall ait une quelconque utilité ; SRS Day Sécurité applicative V.1 Page 40

41 transformer les messages avec XSLT : en utilisant XSLT, il est possible de cacher les schémas internes et ainsi éviter d exposer les structures des documents aux personnes extérieures à l entreprise ; protections XDoS : il est possible d imposer une limite sur le nombre de documents XML parsés et le nombre maximum d éléments et de sous éléments que contiennent ces documents ; valider les XML : vérifier que les documents XML soient bien formés et qu ils respectent certains schémas que l on aura précisés avant. Les récursions infinies et les XML contenant de mauvaises balises sont automatiquement éliminés ; vérification de signature : le firewall peut vérifier que les documents XML ont bien été signés et de manière légitime ; chiffrement/déchiffrement : il est aussi possible de chiffrer ou déchiffrer les documents XML avec des algorithmes comme RSA ou AES. De cette manière, le firewall se comporte comme une sorte de proxy à hautes performances et apporte donc des avantages non négligeables comme une augmentation de la simplicité du code ; en effet, les mécanismes de sécurité sont déportés dans le firewall et le besoin d écrire du code sécurisé dans les applications diminue. Bien sûr, le firewall apporte aussi, dans ce cas-là, une augmentation de la sécurité et de la disponibilité des applications puisqu il agit comme une sorte de nœud central qui filtre et répartit les requêtes avant qu elles n atteignent les applications. Mécanismes de dissimulation La collecte d informations est très importante lors d une tentative d attaque puisqu elle permettra à l attaquant de mieux connaître les systèmes ciblés et donc de créer une attaque sur mesure ou même de trouver des failles existantes du fait de versions logicielles obsolètes. Les firewalls applicatifs offrent des protections contre ces tentatives de collecte d informations en : filtrant les informations du système d opération : dès qu une caractéristique du système d exploitation comme son type (Windows, Linux, etc.) ou son numéro de version est détectée, alors celle-ci est enlevée de la réponse ; cachant les messages d erreurs HTTP : les codes 4xx et 5xx d erreur du client ou du serveur ne sont pas envoyés au client pour éviter au mieux la découverte de comportements non attendus de la part du serveur ; supprimant toutes les pages d erreurs par défaut des serveurs comme Apache et des applications pour éviter que les numéros de version ou des noms d erreurs soient envoyés au client. C est donc une pratique très intéressante puisqu elle complique énormément la tâche des attaquants et rend presque inutile les scanneurs de services. e. Normes de sécurité applicative i. IEEE P1074 SRS Day Sécurité applicative V.1 Page 41

42 Figure 23 : Logo de l'ieee Le standard IEEE P1074 définit une méthode permettant de créer un processus de cycle de vie des projets applicatifs. Il fait partie des rares standards internationaux à traiter du sujet du management du cycle de vie des applications et des systèmes. La principale proposition de ce standard est de faire porter la responsabilité de la sécurité tout au long du cycle de vie du projet de l application aux chefs de projet plutôt que de la faire porter sur le groupe chargé de la sécurité, ce qui est actuellement le cas dans la plupart des entreprises. Cela permet donc de placer la sécurité dans le contexte métier de l entreprise. Ce standard a inspiré les deux normes suivantes : ISO/IEC 17799:2000 Code of Practice for Information Security Management ; ISO/IEC Common Criteria for Information Technology Security Evaluation. Le standard est organisé en 17 groupes d activités totalisant plus de 70 activités, en précisant leurs données d entrée et de sortie. Chaque activité décrit le minimum requis pour produire une composante d une application. Ces activités peuvent être intégrées dans n importe quel cycle de développement d une application. Seul un nombre restreint de ces activités est obligatoire. ii. ISO/CEI 27034:2011 Figure 24 : Logo de l'iso La norme ISO/CEI propose un modèle pour faciliter l intégration de la sécurité dans le cycle des applications. Elle porte aussi bien sur le développement interne que l acquisition ou l externalisation et fournit des lignes directrices pour les processus et les méthodologies de l organisation en question. Elle s intègre facilement aux pratiques courantes de l entreprise telles que le SGSI proposé par la norme ISO/CEI 27001, les processus ITIL, les pratiques de sécurité OWASP ou PCI-DSS, etc. La norme couvre l ensemble des problématiques depuis la protection des informations accessibles par une application jusqu à la prévention d utilisations non autorisées d une application. Elle n impose pas de critères de contrôle ou de règles de développement afin d être aussi générique que possible et d éviter les conflits avec les systèmes actuellement en place. Elle se décompose en 6 parties : aperçu général et concepts (seule partie à avoir été publiée) : présente les objectifs, les destinataires, les acteurs, les concepts, etc. ; cadre normatif de l organisation (draft) : définit les relations et les dépendances existantes entre les processus dans le cadre normatif ; SRS Day Sécurité applicative V.1 Page 42

43 processus de gestions de la sécurité d une application (pre-draft) : décrit les processus liés à la sécurité d une application ainsi que leur relation et dépendance ; vérification de la sécurité d une application (pre-draft) : décrit un processus d évaluation et de validation du niveau de confiance d une application suivant les besoins exprimés ; protocoles et structure de données des contrôles de sécurité applicative (draft) : définit une structure de données commune aux projets de sécurité applicative dont le modèle se base sur l'iso/ts ebxml - Commerce électronique en langage de balisage extensible ; pratiques de sécurité pour des cas spécifiques d applications (draft) : propose un ensemble d exemples de contrôles de sécurité applicative adaptés à des cas de besoins spécifiques. L application de cette norme permet d augmenter de manière considérable la sécurité des applications en agissant directement sur les vulnérabilités identifiées à leur niveau. Elle garantit en outre : la facilitation de conformité aux lois, normes et bonnes pratiques ; l uniformisation et la normalisation de la gestion de la sécurité ; o facilitation du transfert de connaissances ; o réutilisation des processus et contrôles existants ; la gestion optimisée des coûts et de la durée ; une vérification basée sur des preuves ; un meilleur contrôle des intervenants externes. iii. GISSIP Figure 25 : Logo de l'anssi Le Guide d Intégration de la Sécurité du Système d Information dans les Projets définit les différentes actions à effectuer dans le cycle de vie d un projet pour assurer la sécurité du SI. Ce guide n est pas spécifique aux projets liés au développement d une application mais peut aisément s y appliquer. Dans ce but, la méthodologie GISSIP définit un cycle de vie générique qui, selon l interprétation, peut s adapter aux différents cycles de développement (en V, incrémental). Ce cycle de vie comporte 6 parties : l étude d opportunité ; l étude de faisabilité ; la conception générale ; la conception détaillée ; la réalisation ; l exploitation. SRS Day Sécurité applicative V.1 Page 43

44 L intégration de la sécurité dans les projets est basée principalement sur les risques encourus et les mesures adoptées face à ces risques. Il faut donc apprécier les risques, les traiter, les faire accepter par la direction et si besoin effectuer un travail de communication. La particularité de ce guide est d adapter les actions à entreprendre selon le niveau de maturité du SI. Dans le rapport, nous considérons que le SI est mature et est déjà constitué de processus définis et utilisant les bonnes pratiques ainsi qu une méthode d amélioration continue. Nous allons à présent détailler les actions à effectuer lors de chaque étape. Etude d opportunité Le but de cette étape est d analyser les risques liés à la sécurité du système d information en fonction des enjeux du SI et de sa maturité. Pour cela, il faut que les différents responsables de la société (directeur, directeur informatique, directeur financier, directeur RH) soient présents pour avoir une vision d ensemble. A l issue de cette étape, une note d orientation résumant les enjeux du projet est attendue Etude de faisabilité Dans cette étape, l environnement du projet est précisé : comment le nouveau système va s intégrer dans l environnement actuel, à quels besoins (d un point de vue de disponibilité, de confidentialité et d intégrité) le projet doit répondre, quels sont les impacts et les menaces redoutés et les méthodes d attaques possibles. A l issue de cette étape, une note d orientation pour le SSI doit être rédigée. Conception générale Cette étape doit amener à la rédaction du cahier des charges. Celui-ci doit décrire le système à mettre en place, les entités qui le composent et les besoins de sécurité pour chacun des éléments. De plus, l ensemble des menaces envisageables sont décrites avec les risques associés. Finalement, une fiche d expression rationnelle des objectifs de sécurité (FEROS) doit être rédigée en complément du cahier des charges. Conception détaillée Cette étape correspond à la production du cahier de spécifications par le MOE pour établir, entre autres, l ensemble des règles de sécurité qui doivent être appliquées. Pour cela, il faut donc identifier l ensemble des risques et des menaces à partir du cahier des charges et déterminer le traitement des risques associés. Il faut également vérifier la conformité du projet avec la politique de sécurité du système d information. Pour finir, il faut définir quels indicateurs pourront être surveillés par des mesures ou via l écriture de log afin d intégrer le projet dans le tableau de bord du SI. Réalisation A l issue de cette étape, le maître d œuvre doit fournir la version finale du projet, la documentation du livrable et des tests ainsi que le cahier de recette. De plus, le tableau de bord du SI doit être mis à jour en conséquence. Exploitation SRS Day Sécurité applicative V.1 Page 44

45 La phase d exploitation commence avec l homologation de la solution et la mise en place des nouvelles règles de sécurité. Le déploiement du projet est alors effectué puis commence la phase de maintenance, durant laquelle la vérification du bon fonctionnement et du respect des règles de sécurité est effectuée. Ce guide décrit les grandes étapes du cycle de vie d un projet et des actions à prendre en compte et constitue une base pour intégrer la sécurité dans les applications. iv. BSIMM Figure 26 : Logo de BSIMM BSIMM (Building Security In a Maturity Model) est une étude conduite sur 42 entreprises, dont Microsoft, Intel, VMWare (liste complète : qui analyse les décisions et solutions mises en place pour la sécurité des logiciels. De cette étude, BSIMM a tiré 109 activités les plus communes parmi les entreprises (ces activités ne sont pas obligatoires pour assurer une sécurité logicielle). BSIMM n est donc pas un guide indiquant les étapes pour sécuriser son application mais plutôt un référentiel de bonnes pratiques permettant de comparer la gestion actuelle de la sécurité applicative de son entreprise par rapport aux 42 firmes évaluées. A partir de cette comparaison, il est possible de décider quels points doivent être améliorés et quels outils peuvent y aider selon la stratégie ou les objectifs de l entreprise. Les activités sont classées par pratique, elles-mêmes classées dans 4 catégories : Gouvernance : o stratégie et métrique ; o politique et norme ; o formation ; Base documentaire : o modèle d attaque ; o fonctions de sécurité et conception ; o normes et recommandations techniques ; Points principaux du cycle de vie d un développement logiciel sécurisé : o analyse architecturale ; o revue de code ; o tests de sécurité ; Déploiement : o tests d intrusion ; o environnement du logiciel ; o gestion des vulnérabilités et conduite du changement. Dans chacune des pratiques, il existe une dizaine d activités classées en 3 niveaux : le premier étant les actions simples et communes et le dernier les actions difficiles et spécifiques à un domaine. SRS Day Sécurité applicative V.1 Page 45

46 Nous allons à présent nous intéresser aux 12 activités les plus récurrentes au sein de ces 42 entreprises. Gouvernance : o Identifier les points pour la publication et les informations servant à la prise de décision Cette étape a pour but de connaître les différentes étapes du le cycle de vie d un projet où il faut valider certaines données avant de poursuivre le développement. Des jalons bloquants sont ainsi définis et permettent de corriger des erreurs rapidement et efficacement. o Identifier les obligations vis-à-vis des informations personnelles identifiant la personne La gestion des informations personnelles est un sujet sensible. Le groupe de sécurité logiciel doit s assurer que les meilleures pratiques sont mises en place pour protéger ces données et que les lois en vigueur sont respectées. o Promouvoir les sessions de formation Les sessions de formation ont pour but de sensibiliser les personnes à la sécurité lors du développement dans le logiciel. Il est important que la culture de la sécurité devienne naturelle. Il faut bien entendu adapter le niveau du discours au public visé : les développeurs doivent avoir des formations avancées tandis que des introductions peuvent suffire pour les chefs de projet ou responsables. Base documentaire : o Créer un schéma de classification des données Les données gérées par les logiciels doivent être classées dans le schéma créé, le type de classification peut varier d un groupe de logiciel à l autre. Une fois que la classification est terminée, il est plus aisé de déterminer quelles données sont les plus importantes à protéger et ainsi quel logiciel doit être amélioré. o Créer et publier les fonctions de sécurité Les fonctions principales de sécurité telles que l authentification, la gestion des clés et la cryptographie doivent être développées dans un framework propre à l entreprise. Une fois publié, ce framework doit être utilisé par toutes les équipes de développement. Cela permet de faire gagner du temps et, de manière globale, d assurer une meilleure sécurité. o Créer des standards de sécurité Les standards de sécurité correspondent à des bonnes pratiques propres à une technologie. Les fonctions de sécurité sont une partie des standards. Le format de support n est pas seulement papier, il est possible d intégrer des outils aux IDE pour respecter un standard ou fournir des exemples de codes pour expliquer un mécanisme précis. Points principaux du cycle de vie d un développement logiciel sécurisé : o Faire de la revue des fonctions de sécurité SRS Day Sécurité applicative V.1 Page 46

47 Il s agit de la première étape lorsque l on vérifie l architecture d un programme. Après avoir analysé les besoins en sécurité du logiciel, il faut vérifier que l implémentation proposée ne présente pas de cas d utilisation qui permettent de contourner ces fonctions de sécurité. o Utiliser des outils de revue de code automatique Les outils d analyse de code automatique permettent de rendre la revue de code plus rapide et plus efficace. Ces outils ne remplacent pas la revue de code manuelle mais permettent de vérifier des points spécifiques et de remonter certains problèmes de sécurité, qui pourraient passer inaperçus. o Evolution des données d entrée lors de la phase de test de qualité Les équipes qualités (QA) font subir à l application des tests basiques en entrant certaines données au logiciel et attendant une sortie bien précise. En ajoutant des tests contenant de mauvaises données, il devient plus facile de relever les problèmes. Déploiement : o Employer une équipe de tests d intrusions externes Si la sécurité n a pas été prise en compte au lancement du projet, faire un test de pénétration par une équipe externe permet de relever rapidement les problèmes et conseiller sur les solutions à retenir. Il est possible à partir de ces problèmes d améliorer l organisation lors de la session de développement. Il est préférable d utiliser une équipe externe pour avoir un regard neuf sur la situation. o S assurer que le système hôte et le réseau soient sécurisés La sécurisation de l hôte et du réseau constitue le socle pour la sécurité de l application. Il est important de mettre à jour la machine hôte et de vérifier les règles de firewall pour assurer une bonne sécurité pour l application. o Identifier les défauts via la surveillance et les signaler aux équipes de développement En surveillant les applications, les équipes opérationnelles peuvent relever des problèmes sur certaines d entre elles et les signaler aux développeurs pour qu ils puissent les corriger et modifier leurs techniques de développement. BSIMM propose donc de nombreuses pratiques qui peuvent améliorer facilement la sécurité au niveau applicatif. La possibilité de comparer le niveau de son entreprise par rapport aux entreprises évaluées est un point qui facilite la prise de décision et qui rend cette méthode intéressante. v. OWASP SRS Day Sécurité applicative V.1 Page 47

48 L OWASP est une organisation mondiale à but non lucratif recherchant l amélioration du niveau de sécurité des applications à travers, entre autres, la production d outils et de documents dédiés. Figure 27 : Logo de l'owasp L ensemble des ressources fournies par l OWASP adresse la sécurité des applications selon une approche visant à répondre aux problèmes technologiques, organisationnels et humains. Les différents projets se concrétisent sous forme de présentations, de guides, d outils logiciels, de listes de contrôle, d environnements de sensibilisation et d autres supports pouvant aider les entreprises. Parmi les catégories d outils et de documents on distingue : ceux pouvant être utilisés pour se protéger des défauts d implémentatoin ou de conception liés à la sécurité des applications o AntiSamy - API pour valider les entrées en évitant les attaques XSS ou par hameçonnage ; o Enterprise Security API - recueil des méthodes de sécurité pour les applications ; o Development Guide - ouvrage pour la création d applications Web sécurisées à l'intention des développeurs, concepteurs et architectes ; o Secure Coding Practices - ensemble de bonnes pratiques ; o etc. ceux servant à détecter ces défauts o WebScarab - outil permettant d effectuer des tests de sécurité sur les applications Web et les services Web ; o Code Review Guide - ouvrage destiné à la relecture du code ; o Testing Guide - ouvrage dédié à l audit de sécurité des applications ; o etc. ceux permettant d ajouter des activités liées à la sécurité dans le cycle de vie du développement d une application o WebGoat - outil d entrainement à la détection et l exploitation de failles applicatives ; o AppSec FAQ - guide regroupant un ensemble de questions/réponses sur les bonnes pratiques face aux problèmes récurrents (gestion des identifiants, authentification, etc.) ; o CLASP - guide indiquant des processus s intégrant dans le développement pour assurer une meilleure sécurité ; o etc. Ces ressources sont utilisées comme références pour les concepteurs et développeurs mais servent également de support pour des campagnes de sensibilisation et de formation des utilisateurs. SRS Day Sécurité applicative V.1 Page 48

49 Selon l OWASP, la sécurité logicielle s applique à tous les niveaux d un projet, son framework de test intervient dans les activités suivantes : avant la phase de développement : vérifier la politique, les normes, la documentation, etc. ; conception : vérifier la conception architecturale, les modèles UML, les modèles de menace, etc. ; développement : vérifier si le code source ne possède pas de failles de sécurité (revue de code, tests unitaires, etc.) ; déploiement : vérifier que le projet est prêt à être finalisé et mis en production (tests d intrusion en boîte noire, vérification des configurations, etc.) ; maintenance : contrôler la réalisation de la conduite de changement, vérifier le bon fonctionnement, tests de régression, etc. vi. OpenSAMM Figure 28 : Logo de l'opensamm L OpenSAMM (Software Assurance Maturity Model) est un projet supporté par l OWASP dont le but est de fournir un utilitaire permettant la mise en place d une stratégie de mise à niveau de la sécurité des applications. Celle-ci s effectue à travers l analyse des pratiques actuelles, la définition des axes d'amélioration et l'établissement d'un planning permettant de mesurer l efficacité des moyens mis en œuvre. Le projet SAMM découpe le développement d une application en 4 grandes parties, ou fonctions business, chacune étant à leur tour définit par 3 activités. Il y a donc au total 12 activités mises à disposition. Afin de permettre la mise en place du projet SAMM pour toutes les entreprises, chacune des activités possède 3 niveaux de maturité pour préciser les actions à entreprendre et améliorer le niveau de sécurité des applications. Figure 29 : Présentation des activités de la méthodologie SAMM Ces activités se décomposent de la manière suivante : SRS Day Sécurité applicative V.1 Page 49

50 Gouvernance : o Stratégie et métrique Le but de cette activité est d identifier et de classifier les risques ainsi que de créer un planning de mise en œuvre des améliorations. o Conformité et politique de sécurité Cette activité a pour finalité d'identifier les différentes contraintes pesant sur l entreprise et de les prendre en compte dans la politique et dans les processus de sécurité lors du développement d application. o Conduite de changement Cette activité a pour objectif de préparer la conduite de changement auprès de tous les acteurs du cycle de vie de l application. Construction : o Evaluation des menaces Dans cette étape, les menaces propres au logiciel et à l environnement sont identifiées. o Prérequis d architecture Cette activité permet de définir les procédés techniques à utiliser lors du développement de l'application selon les besoins sécurités métiers exprimés. o Architecture sécurisée L objectif de cette activité est de définir et développer les méthodes et outils de travail qui permettront d améliorer la sécurité des projets de manière globale dans l entreprise. Vérification : o Revue des fonctionnalités Cette étape sert à vérifier que le code source respecte l architecture ainsi que les règles de sécurité définies précédemment. o Revue de code La revue de code permet de détecter d'éventuelles failles de sécurité ou défaut de conception dans le code source. o Tests de sécurité Cette activité a pour but de tester l application dans l environnement de production afin de détecter les problèmes liés à la sécurité. Déploiement : o Gestion des vulnérabilités Cette activité permet de mettre en place une gestion des vulnérabilités au sein de l entreprise. o Durcissement de l environnement Cette activité a pour but d améliorer la sécurité de l environnement de l application et ainsi réduire les risques liés à ce dernier. o Activation opérationnelle SRS Day Sécurité applicative V.1 Page 50

51 Cette activité a pour but d améliorer la communication auprès des utilisateurs des problèmes de sécurité liés à l application lors des déploiements en créant des guides et des procédures. SRS Day Sécurité applicative V.1 Page 51

52 7. Les processus opérationnels des fonctions sécurité Un projet se découpe généralement en deux phases : le Build et le Run. La phase de Build correspond à la conception, au développement et au déploiement de la solution tandis que la phase de Run correspond à l exploitation, la maintenance ainsi que l ensemble des actions de support, de changement et de gestion de l application. Figure 30 : Organisation des phases de Build et de Run dans un projet Certains processus se situent aussi bien au niveau du Build que du Run et seront donc listés dans la phase où ils interviennent en premier lieu. a. Processus du build Intégration de la Sécurité dans les Projets (ISP) L intégration de la sécurité dans les projets regroupe 3 processus. Les outils de développements en sont le socle principal mais il en existe d autres qui sont tout aussi utiles. L ISP est détaillée davantage dans la partie suivante, nous présentons ici les processus sécurité qui sont concernés. o Gestion de la sécurité dans les projets SI Ce processus décrit les différentes étapes du cycle de vie d un projet dans lesquelles le département sécurité de l entreprise doit jouer un rôle : il est chargé d analyser un projet pour en identifier les risques, de faire des recommandations sur les technologies utilisées, de valider les documents d architecture technique, de se rendre disponible tout au long du développement, de participer à la phase de recette, d aider à la mise en production et de prendre part à la maintenance. Pour cela, l entité sécurité peut utiliser plusieurs ressources telles que des guides, des bonnes pratiques ou des fiches détaillées. Il est important que l ensemble des projets prennent en compte l aspect sécurité pour protéger les informations manipulées, qui représentent aujourd hui la richesse de l'entreprise. Le guide intitulé GISSIP récapitule les différentes actions à effectuer dans la vie d un projet. o Expertise sécurité et support aux projets SI Ce processus explicite le devoir de conseil des équipes sécurité face aux questions qui leur sont posées par les autres services. Elles doivent aussi prendre en charge la maintenance des projets pour assurer le niveau de sécurité exigé. La gestion des questions peut être menée de plusieurs manières. Il est conseillé de regrouper les questions et les réponses dans une base de connaissances accessible à tous, avec l utilisation de wiki ou de sites internes basés sur StackOverFlow. Il est SRS Day Sécurité applicative V.1 Page 52

53 également possible de formuler des demandes via les outils de gestion de versions pour effectuer un travail de revue de code sur une fonctionnalité. La maintenance des projets est un point complexe. En effet, chaque projet a un environnement propre et il faut faire évoluer l application avec celui-ci. Les actions les plus communes sont les mises à jour liées à l environnement et la correction de problèmes (bugs). Cependant, déployer des patchs peut impliquer une organisation spécifique dans certains cas. Lorsqu une application est déployée sur un parc entier, il faut s assurer que le patch n aura aucun impact fonctionnel sur celui-ci. Le cycle général pour déployer un patch est le suivant : Figure 31 : Cycle générique du déploiement d'un correctif Ce cycle est long et n est pas forcément adapté à toutes les situations. Il faut donc définir une politique de patch qui précise les actions à entreprendre pour chaque étape selon l importance du patch. o MOA/MOE des projets sécurité Ce processus décrit les projets qui sont propres aux équipes sécurité dont l objectif n est pas de générer du chiffre d affaires mais plutôt d améliorer la sécurité du SI de l entreprise. Il est important de noter que ces projets sont de plus en plus menés par les équipes de production et non les équipes du RSSI : la gestion opérationnelle de la sécurité est principalement prise en charge par des collaborateurs qui sont hiérarchiquement rattachés aux équipes de sécurité mais qui travaillent à la production au jour le jour. Un des projets les plus représentatifs de ce processus est la mise en place d une PKI. Ces projets sont critiques et doivent donc prendre en compte toutes les recommandations de sécurité, les outils et les bonnes pratiques lors de leur développement et de leur déploiement. Comme ces projets visent à améliorer la sécurité générale du SI, il faut essayer d intégrer ces améliorations dans les applications concernées. Cela peut signifier de nouveaux déploiements et des coûts supplémentaires mais permet de se protéger plus efficacement de certaines menaces. Sensibilisation et formation des développeurs Ce nouveau processus vient s ajouter à la liste de processus opérationnels existants dans le but d obtenir une gestion optimale de la sécurité applicative dans un projet. En effet, celui-ci est rarement mis en place de manière efficace pour les équipes de développement dont les priorités tendent à s éloigner de celles des équipes de sécurité. SRS Day Sécurité applicative V.1 Page 53

54 L objectif est de mener une campagne de sensibilisation et de formation aux outils techniques disponibles en organisant des réunions ou des conférences en amont de la phase de développement et de maintenir une mise à niveau continue sur les bonnes pratiques et les généralités de la sécurité (IAM, PKI, etc.). Ces formations permettent de présenter les cas d utilisation des outils ainsi que leur prise en main. Ce processus est transverse et cible en priorité la MOA/MOE pour prendre en compte la gestion de la sécurité applicative dans leur budget, planning, etc., mais également les architectes, les concepteurs, les développeurs, les testeurs et la maintenance. Standards techniques de sécurité Ce processus détaille les étapes permettant de rédiger et mettre à disposition des guides pratiques d aide à l utilisation des outils de sécurité applicative pour le métier de l entreprise. Ce socle technique intègre les documents d'installation sécurisée des applications (exemple : guide de durcissement pour Windows Server 2008), la normalisation produit (type et version de firewall, niveau de patches, etc.) ainsi que les règles techniques. Il consiste à fournir des documentations liées aux dispositifs de sécurité mis en place (exemple : PKI). Par ailleurs, il repose sur le référencement et la documentation des frameworks de développement listés plus haut qui vont permettre aux équipes développement de prendre en considération l ensemble des aspects qui y sont abordés au moment d écrire leurs applications. Finalement, les guides pratiques devront s assurer du respect des normes (ISO 27034, OWASP, etc.) dans la réalisation du projet. b. Processus du run Contrôles opérationnels Lorsqu une application est en production, il est conseillé de vérifier sa sécurité régulièrement. La périodicité de ces tests varie selon la criticité de l application d une part, de la pertinence et de la difficulté de mise en œuvre de ces tests d autre part. Par exemple, un test d intrusion sera fait une fois par an tandis que des scans de vulnérabilités automatiques peuvent être lancés toutes les deux semaines. Ces tests permettent de vérifier le bon fonctionnement des dispositions de sécurité mises en place dans un environnement réel et peuvent aussi permettre d identifier des vulnérabilités résultant de la mise à jour d un élément de l environnement ou d un patch appliqué à l application. Pour ce faire, de nombreux outils peuvent être utilisés : des scanneurs de vulnérabilités, des audits comportant des tests d intrusion ou des revues de codes sur certains éléments. De nombreuses entreprises proposent des scanneurs de vulnérabilités : Qualys, McAfee, IBM, HP et d autres (cf. état de l art). Les tests d intrusion, quant à eux, sont généralement réalisés par des sociétés spécialisées. Les outils de revue de code sont généralement des outils permettant de vérifier, à travers l analyse statique du SRS Day Sécurité applicative V.1 Page 54

55 code, des erreurs de sécurité (exemple : Sonar ou FindBugs pour des développements Java). Administration/configuration des équipements de sécurité La sécurité applicative ne repose pas uniquement sur le logiciel en lui-même mais sur l environnement qui le supporte. Cet environnement est composé de serveurs, de parefeu et dépend de certains frameworks. La plupart du temps, des outils, des fonctionnalités ou des comptes sont installés ou créés pour aider lors des premières utilisations. Cependant il s agit de configurations communes à tous les équipements dont les informations sont publiques et mises à disposition sur Internet gratuitement. Il est donc conseillé de supprimer ou modifier ces configurations par défaut après le déploiement. De même, les mises à jour de ces produits doivent être prises en compte. Selon le top 10 de l OWASP, les cas d erreurs de configuration des équipements de sécurité figurent en 6ème position et semblent être en hausse par rapport aux années précédentes. En supplément des configurations individuelles de chaque équipement, il faut s assurer que les configurations sont complémentaires et ne provoquent pas de vulnérabilités dans un autre équipement. L équipe eeye Research propose un outil gratuit qui permet de réaliser des tests automatiques sur les différentes configurations d un environnement. Néanmoins, ces outils se font pour le moment assez rares et sont peu intégrés par les entreprises. Veille sécurité et gestion des vulnérabilités La mise en place d une veille sécurité efficace permet de connaître au plus tôt les menaces auxquelles peut être exposée une entreprise et ainsi s en protéger efficacement. En effet, il ne faut pas oublier que la sécurité passe par l information avant les outils techniques. Elle permet d alerter en amont d une vulnérabilité et de profiter de cet avantage pour tester les correctifs, changer les configurations des systèmes à risques, etc. Pour ce faire, un responsable de la veille doit être désigné et les sources d informations à suivre doivent être définis. Il est cependant essentiel de s abonner uniquement à des listes de diffusion dédiées à la sécurité applicative. Quelques exemples : - OWASP : - Bee Ware : - DenyAll : À partir de cette veille ou de remontées d alertes, des vulnérabilités peuvent être identifiées. Pour évaluer leur criticité et ensuite les classer, il est possible d utiliser des fiches CVSS (système d'évaluation standardisé de la criticité des vulnérabilités). Une fois ces fiches établies, il faut décider du correctif à appliquer puis procéder au déploiement d un patch de sécurité. Gestion et supervision des incidents et des événements SRS Day Sécurité applicative V.1 Page 55

56 Aujourd hui, tous les équipements d infrastructure de sécurité tels que les firewalls et les proxy produisent des logs qui sont collectés par des solutions de SIEM (Security Information and Event Management) puis régis par des règles de contrôle, dont l objectif est de lever une alerte selon le type du log (ex : détection d un cas de scan de port). Embarquer la gestion des journaux directement dans l application étant difficilement atteignable dans les faits, ce processus vise donc à intégrer aux projets des équipements de traçabilité des actions applicatives SIEM (ex : Citrix - détection de tentative de hack, monter un partage réseau, placer un binaire, etc.), tels que NetWrix, Varonis, Stealthbits, etc. SRS Day Sécurité applicative V.1 Page 56

57 8. Méthode d intégration de la sécurité applicative dans un projet a. Gestion de la sécurité applicative dans un nouveau projet Le cycle de vie d une application désigne toutes les étapes de son évolution, de sa conception à sa disparition. L'objectif d'un tel découpage est entre autres de définir des jalons intermédiaires permettant de valider la conformité de l application avec les besoins exprimés et de réduire les coûts des erreurs détectées trop tardivement. Dans le cadre de la sécurité applicative, il permet d intégrer la sécurité au cycle de vie d une application selon les étapes d une démarche projet déjà largement répandue et éprouvée. i. Phase de pré-étude La phase de pré-étude, aussi appelée analyse des enjeux, permet d une part de définir les objectifs en déterminant la finalité du projet et son inscription dans une stratégie globale, et d autre part d effectuer une analyse de faisabilité en exprimant l ensemble des besoins et des contraintes. Dans le cadre de la sécurité applicative, cette phase doit permettre : de vérifier l adéquation entre la PSSI de l entreprise et l application, d identifier les objectifs de sécurité que l application doit mettre en œuvre pour se protéger elle-même et ceux qui seront déportés sur l infrastructure, et de procéder à une analyse des risques engendrés par l exploitation de l application, les données qu elle traite, et l intervention de tiers (prestataires, sous-traitants, etc.). La sensibilisation des chefs de projets MOA/MOE aux problématiques de sécurité est indispensable à la bonne réalisation de cette phase. Il est à noter que les méthodologies d'identification des objectifs de sécurité et d analyse de risques courantes, comme EBIOS, MEHARI ou encore OCTAVE, sont jugées trop longues à mettre en œuvre et trop contraignantes en termes de moyens à investir pour être ici appliquées. On préférera le simple suivi de normes plus flexibles comme l ISO/IEC 27005, qui étaye les concepts généraux spécifiés dans l ISO/IEC relative aux Systèmes de Management de la Sécurité de l Information (SMSI), pour la partie gestion du risque. Les risques liés à l intervention de tiers dans le cycle de vie de l application peuvent par ailleurs être adressés par le biais de standards existants, tels que le projet OWASP Legal et son contrat permettant de négocier et de capturer les principaux termes et conditions contractuelles relatives à la sécurité de l application. ii. Phase de spécifications La phase de spécifications techniques et fonctionnelles permet d élaborer l'architecture générale de l application selon l ensemble explicite des exigences déterminées lors de la phase de classification et des processus métier dans lesquels l application devra intervenir. SRS Day Sécurité applicative V.1 Page 57

58 Dans le cadre de la sécurité applicative, cette phase doit permettre de : faire intervenir la sécurité dans le choix des technologies principales à utiliser, d isoler les données et processus sensibles, de définir un planning indiquant les jalons de sécurité avec leurs prérequis de validation, et de faire intervenir la sécurité dans la définition des cahiers de tests qui viendront éprouver l application. La sensibilisation des architectes aux problématiques de sécurité est indispensable à la bonne réalisation de cette phase. Plusieurs des problématiques de cette phase et des suivantes peuvent être adressées notamment par le biais des activités décrites dans l étude BSIMM ainsi que par le projet OWASP CLASP qui fournit une approche structurée pour intégrer la sécurité dès les premiers stades du cycle de vie d une application. iii. Phase de conception La phase de conception permet de définir précisément chaque sous-ensemble de l application, toujours dans ses aspects techniques autant que fonctionnels. Dans le cadre de la sécurité applicative, cette phase doit permettre de faire intervenir la sécurité dans le choix : des bonnes pratiques à suivre, des préconisations d orientations techniques, de la modélisation et du découpage interne de l application, de l environnement d exécution et des différents frameworks de sécurité à utiliser. La sensibilisation des concepteurs aux problématiques de sécurité est indispensable à la bonne réalisation de cette phase. Une approche globale, en suivant l analyse des risques du SI effectuée lors de la phase de classification, est possible aussi bien qu une approche locale par isolation des différents modules composant l application. Les questions soulevées par la mise en œuvre de cette phase de conception d une application peuvent notamment être adressées par le projet OWASP AppSec se présentant sous la forme d une FAQ répondant à un large panorama d interrogations que les développeurs auront à propos de la sécurité des applications. iv. Phase de développement La phase de développement n est pas un simple exercice de programmation. Il s agit de traduire et d implémenter les fonctionnalités définies lors des phases de spécifications en un ensemble cohérent et à l aide des technologies et des techniques retenues lors de la phase de conception. Dans le cadre de la sécurité applicative, les spécifications et les décisions arrêtées lors de phase de conception en termes de sécurité ne sont pas toujours exhaustives. Le bon déroulement de cette phase relève alors de la responsabilité, des compétences et de l expertise des développeurs en termes de sécurité. La sensibilisation des développeurs aux problématiques de sécurité est donc indispensable à la bonne réalisation de cette phase. Eclatement, simplification et revue du code source, utilisation de bibliothèques standards réputées, intégration de fonctionnalités de sécurité basiques, principe de SRS Day Sécurité applicative V.1 Page 58

59 séparation du moindre privilège, mise en place de mécanismes d authentification diverses et fortes, filtrage des connexions, chiffrement des échanges, vérification des flux de données... tous sont autant d exemples que la formation des développeurs à la sécurité doit permettre de mettre en place automatiquement. Il est à noter que la documentation visant à produire les informations nécessaires pour l'utilisation de l application et pour des développements ultérieurs laisse souvent à désirer lors des phases de développements. Or, la qualité de celle-ci ne doit pas être sous-estimée, elle met en évidence les liens structuraux d un système et les relations entre les processus et les données traitées, elle peut ainsi contribuer à détecter les défauts de conception d une application et de travailler son niveau de sécurité. Un grand nombre d outils et de guides d aide sont aujourd hui à la disposition des développeurs, on peut notamment citer les projets de l OWASP : OWASP Development Guide, OWASP Code Review Guide, OWASP Code Crawler, OWASP Secure Coding Practices, OWASP Enterprise Security API, etc. v. Phase de tests La phase de tests peut être plus ou moins fine, et par conséquent l'effort de test plus ou moins important selon le niveau de qualité requis, ce dernier devant être adapté en fonction de la complexité et de la criticité des applications. Dans le cadre de la sécurité applicative, on distinguera : les tests unitaires, permettant de vérifier individuellement que chaque sous-ensemble de l application est implémenté conformément aux prérogatives de sécurité déterminées lors de la phase de conception ; les tests d intégration, dont l'objectif est de s'assurer de l'interfaçage des différents modules applicatifs en un ensemble robuste ; et les tests de qualification, aussi appelés de recette, permettant la vérification de la conformité de l application avec les spécifications de sécurité initiales en répétant divers scénarios d utilisation. La sensibilisation des testeurs aux problématiques de sécurité est indispensable à la bonne réalisation de cette phase. Malgré les variations existantes utilisées par les entreprises, on retrouve toujours une approche itérative par cycle dans les phases de tests. Cette démarche s inscrit dans une volonté d exhaustivité et peut être accompagnée par les méthodologies et guides existants, comme notamment l OWASP Testing Guide, un projet se concentrant sur les procédures de tests en matière de sécurité et les listes de contrôle. Cette phase permet par ailleurs de déterminer le niveau de maturité de l entreprise en termes de sécurité applicative. La quantité et la qualité des tests servent d indicateurs pour comparer le niveau de sécurité recherché par rapport à celui atteint par les différents acteurs du marché. SRS Day Sécurité applicative V.1 Page 59

60 Figure 32 : Schéma de la maturité de la sécurité applicative des entreprises vi. Phase de déploiement La phase de déploiement englobe la succession du passage de l environnement de développement à celui de pré-production, puis celle du passage de ce dernier à celui de production. Cette migration en deux étapes est nécessaire afin que l application soit officiellement reconnue et utilisée par l organisation. Dans le cadre de la sécurité applicative, l environnement de pré-production doit permettre : de valider l intégration de l application en testant sa capacité à évoluer sur le système auquel elle est destinée, de valider les processus de configuration de l application et de ses supports (OS, réseau, etc.), et d éprouver l application dans une situation analogue à la réalité en effectuant des tests d intrusion, des scans de vulnérabilités et des tests de montée en charge. La sensibilisation des intégrateurs aux problématiques de sécurité est indispensable à la bonne réalisation de cette phase. Les éditeurs des solutions permettant de réaliser les tests suscités ne manquent pas et les outils font légion, un amalgame étant souvent fait entre la sécurisation d une application et la recherche de vulnérabilités. vii. Phase de maintenance La phase de maintenance rassemble toutes les actions correctives et évolutives permettant d améliorer le niveau de service et la fiabilité de l application, d assurer son maintien en conditions opérationnelles et d en maitriser et réduire les coûts. Dans le cadre de la sécurité applicative, cette phase est essentielle et constitue la suite logique aux activités de veille, de gestion des vulnérabilités et de gestion des correctifs de sécurité. Afin d éviter des effets de bord aux conséquences non-maitrisées, les mises SRS Day Sécurité applicative V.1 Page 60

61 à jours applicatives doivent être effectuées dans des environnements de préproduction et faire l objet de tests préalables. La sensibilisation des mainteneurs aux problématiques de sécurité est indispensable à la bonne réalisation de cette phase. La maintenance d une application est une phase s inscrivant dans la durée et dont l historique peut parfois atteindre des proportions difficilement appréhendable. Des outils permettant aux professionnels de la sécurité de profiter d un moyen de signaler et de garder une trace des modifications effectuées sur un projet existent et sont indispensable à la pérennité d une application. On pourra notamment citer l OWASP Report Generator. Figure 33 : Schéma de synthèse de l'intégration de la sécurité dans un nouveau projet b. Intégration de la sécurité applicative dans un projet existant L intégration de la sécurité applicative sur un projet existant correspond au besoin le plus fréquent pour un organisme. En effet, leur nombre est généralement bien supérieur à celui de projets nouvellement démarrés au sein d une entreprise. Par ailleurs, ces applications déjà en production sont le résultat d une conception sans considération SRS Day Sécurité applicative V.1 Page 61

62 pour la sécurité, se sont vues transformées au cours de nombreuses évolutions répondant aux besoins des utilisateurs et sont parfois peu connues des équipes sécurité. L intégration de la sécurité à ces applications représente une charge de travail bien supérieure à celle demandée pour un projet naissant. La prise en main par les équipes sécurité, les phases de compréhensions, de cartographie de l architecture interne de l application, de détections des défauts et failles exploitables, de corrections, et enfin de mises à jour dans l environnement de production peuvent engendrer des coûts importants. Les principes pour intégrer la sécurité seront finalement les mêmes que pour un nouveau projet. Cependant, certaines contraintes et spécificités sont à prendre en compte tout au long du processus et lors du choix des solutions. i. Contraintes et analyse contextuelle Lors de l intégration de la sécurité applicative à un projet existant, celle-ci doit faire l objet d une phase d étude permettant d appréhender l architecture interne de l application ainsi que ses engrenages et de déterminer tous ses axes d utilisation en production. En suite à cette étape d observation, l identification et l analyse des besoins en termes de sécurité pour l application doit permettre de mettre en évidence les manquements à la PSSI en place et de sélectionner les objectifs de sécurité que l application doit mettre en œuvre pour se protéger. Une attention particulière doit être portée à cette étape afin de ne pas dupliquer un mécanisme de sécurité déjà procuré à l application par le biais de l infrastructure de l entreprise. En second lieu, l analyse des contraintes en termes de prérequis relatifs à l environnement de support, de sensibilité des données, de gestion des accès, et de traitement des flux entrants ou sortants doit permettre de retenir ou d exclure d emblée des solutions de sécurité parmi celles qui seront amenées à être ultérieurement déployées. Cette phase d analyse contextuelle permet de placer le projet existant dans un cadre de sécurité précis et de définir un périmètre d intervention pour la suite de l intégration. ii. Identification des principaux risques Une fois la phase d analyse contextuelle achevée, l application doit faire l objet d une enquête minutieuse. Celle-ci est effectuée dans le but de déterminer sa criticité pour le cœur de métier de l entreprise et les implications d une déficience au niveau opérationnel sur la production. En parallèle, dans un environnement de pré-production, des batteries de tests variés doivent permettre de dresser une liste idéalement exhaustive des vulnérabilités, des défauts de conceptions de l application et des axes d amélioration de son niveau de sécurité. SRS Day Sécurité applicative V.1 Page 62

63 Cette liste doit finalement être complétée afin de décrire les impacts de chacun des éléments qui la compose, puis permettre de servir de support à une analyse complète et quantifiée des risques applicatifs. Enfin, la combinaison du résultat de cette analyse et de l évaluation des ressources disponibles ainsi que du budget nécessaire aux correctifs doit permettre d établir des priorités concernant l intégration de la sécurité à l application ainsi que les objectifs en termes de risques résiduels. iii. Identification des solutions potentielles en fonction du contexte A l issue de ces deux phases, toutes les informations préalables aux choix des solutions permettant d intégrer la sécurité applicative au sein du projet sont réunies. Pour chaque risque identifié, et parmi l ensemble des solutions établies par les équipes sécurité au regard des besoins identifiés lors de l analyse contextuelle, le tri doit être effectué en fonction des informations précédemment collectées, en considérant les contraintes aussi bien techniques qu opérationnelles. Il est à noter qu au sein d une entreprise, le choix final des solutions à mettre en place relèvera toujours de décisions de l ordre du niveau stratégique. L évaluation des compromis entre les risques, de leur priorité de traitement et des coûts qu ils engendrent est donc une étape indispensable. iv. Mise en place des correctifs Afin d intégrer parfaitement les solutions retenues à l architecture interne de l application, les correctifs de sécurité doivent être soit entièrement développés, soit adaptés de versions existantes. Une fois ces correctifs prêts, ils doivent être déployés et éprouvés dans un environnement de pré-production. Plusieurs batteries de tests, similaires à ceux effectués lors de la phase d analyse des risques, doivent permettre de valider l efficacité de la solution mais également de détecter toute régression. Les correctifs de sécurité doivent être réversibles, afin de pouvoir revenir à un état nominal de l application en cas d altération de son fonctionnement. Le déploiement en production doit quant à lui impérativement être coordonné avec le métier que l application supporte. Dans la majorité des cas, celui-ci ne pourra s effectuer qu en dehors des jours ouvrables ou des horaires de travail. Enfin, si les correctifs impliquent une modification fonctionnelle pour les utilisateurs, une campagne d accompagnement de ces derniers et de conduite du changement doit être menée afin de minimiser les arrêts de service et les pertes financières associées. SRS Day Sécurité applicative V.1 Page 63

64 Figure 34 : Schéma de synthèse de l'intégration de la sécurité dans un projet existant c. La sécurité applicative dans le cas des progiciels et développements externalisés Pour l entreprise nécessiteuse, il n est pas toujours trivial d engager le budget ni de rassembler l expertise nécessaire au développement et au maintien d une solution répondant au besoin qu elle cherche à combler. Dès lors, le parc logiciel d une entreprise agrège fréquemment des applications de type progiciel ou issues de développements spécifiques mais externalisés. On peut citer notamment les ERPs, les CRMs et les SCMs, souvent originaires d un achat ou d une prestation réalisée auprès d un tiers. Le coût de mise en œuvre de telles applications est théoriquement moins élevé que le coût d un projet interne et les délais mieux maitrisés, néanmoins l intégration de la sécurité à ces applications s en retrouve complexifiée à hauteur du niveau d implication des tiers concernés. Les outils d infrastructures tels que les pare-feu applicatifs sont la première brique permettant cette intégration, mais d autres actions peuvent être engagées pour consolider la sécurité des applications externalisées. Les principes pour intégrer la sécurité à un projet effectué en partenariat avec des tiers sont finalement toujours les mêmes que pour le démarrage d un nouveau projet. Cependant, certaines phases étant entièrement ou partiellement déléguées, l entreprise bénéficiaire doit se positionner selon un rôle de validateur, se protéger légalement, et s appliquer à renseigner ses prestataires sur les contraintes et les spécificités de son métier à prendre en compte tout au long du processus et lors du choix des solutions. i. Aspects légaux et attribution des responsabilités Lorsque le développement d une application est externalisé, un contrat portant sur la prestation de service sera immanquablement établit entre les différentes parties contractantes. SRS Day Sécurité applicative V.1 Page 64

65 La sécurité du patrimoine informationnel ou des supports protégés de l entreprise doit alors impérativement être garantie par l'insertion d une clause de confidentialité mentionnant la désignation, le niveau et les conditions de protection dont chaque information doit faire l'objet, en plus des lieux d'exécution des différentes phases du projet et les mesures particulières de sécurité qui doivent être prises pour l'exécution de la prestation. Ledit contrat doit par ailleurs avoir pour objet une tâche précise qui nécessite un savoirfaire particulier que l entreprise cliente n est pas capable d assumer en interne. Les responsabilités de chacun des protagonistes doivent être clairement définies et explicitées afin d éviter des conflits ultérieurs, d éventuels avenants, et plus généralement des surcoûts. Enfin, une clause assurant à l entreprise solliciteuse l auditabilité de son prestataire ou de son fournisseur et du produit ou des services vendus est un critère de transparence essentiel à la communication et à la protection des actifs de l entreprise. ii. Renseignement, définition des besoins et validation des solutions Les accords commerciaux une fois validés sur le plan légal, le projet de développement externalisé et par conséquent le cycle de vie de l application sont entamés. Il est alors de la responsabilité de l entreprise de fournir toutes les informations suffisantes et nécessaires à l accomplissement de la prestation. Les contraintes, les spécificités de son cœur de métier et ses besoins en termes de sécurité doivent être clairement renseignés afin d assurer la conformité de l application développée par le tiers avec la PSSI de l entreprise. L entreprise demandeuse doit également prendre part aux phases de spécifications et de conceptions en impliquant les cellules de sécurité dans le processus de décision et en les positionnant comme validateurs légitimes des cahiers de tests et des solutions retenues par le maitre d œuvre. iii. Recette sécurité et déploiement Une fois la phase de développement du projet achevée par le prestataire, la phase de recette rassemble ce dernier et l entreprise afin de vérifier que le produit est conforme aux attentes formulées en amont. Le respect des contraintes et des spécificités du cœur de métier de l entreprise ainsi que de ses besoins en termes de sécurité doit alors être vérifié. Pour ce faire, l application doit être auscultée selon les cahiers de tests rédigés au préalable et en accord avec la clause relative à l auditabilité établie lors de la rédaction du contrat. Que ce soit dans le cas d un contrat de service ou de vente, il est fortement recommandé d impliquer contractuellement le prestataire ou le fournisseur dans les phases de pré-déploiement en environnement de test et de déploiement en environnement réel. Les erreurs de configurations et les problèmes d intégration sont en SRS Day Sécurité applicative V.1 Page 65

66 effet courant et opérer seul peut nécessiter pour l entreprise : d une part la création involontaire de failles de sécurité, et d autre part une longue et couteuse étape de montée en compétence. iv. Surveillance et maintenance Une fois l application déployée, assurer son maintien en conditions opérationnelles et en maitriser les coûts peut à nouveau nécessiter une expertise que l entreprise bénéficiaire ne peut ou ne sait engager, pour des motifs budgétaires ou de compétences. Que ce soit dans le cas d un contrat de service ou de celui d un contrat de vente, il est alors fortement recommandé d impliquer contractuellement le prestataire ou le fournisseur sur sa disponibilité en termes de service après-vente et dans le cycle de gestion des correctifs de l application. Deux solutions sont couramment mis en place : ou celui-ci doit être tenu de recueillir les incidents applicatifs, de procéder à une veille des vulnérabilités applicatives et s engage à les traiter ; ou bien celui-ci doit s engager à effectuer un transfert de connaissance associée d une documentation complète et d une formation des futures équipes internes responsables de l application. SRS Day Sécurité applicative V.1 Page 66

67 Figure 35 : Schéma de synthèse de l'intégration de la sécurité dans un projet externalisé SRS Day Sécurité applicative V.1 Page 67