vendredi 3 juillet 2020    || Inscription
BanniereNews
 
 
Démystifier les idées reçues

IMG/jpg/Logo_People_Security.jpg
Depuis quelques années, la sécurité logicielle et ses vulnérabilités sont en point de mire, et les entreprises font de leur mieux pour déjouer les risques que peuvent introduire des politiques de sécurité logicielle inadaptées. Certes, la nature de ces risques est désormais mieux comprise, mais les approches qui assurent une protection efficace du parc applicatif restent encore mal connues. Dans cet article, nous allons revenir sur certains des mythes les plus répandus en matière de sécurité, partant du principe que pour améliorer la sécurité logicielle, il faut au préalable se débarrasser de ces idées reçues. En accordant foi à ces sept « mythes capitaux », vous risquez de perdre un temps précieux en déployant des stratégies de « sécurité » qui s´avèrent au final inutiles. Pire, vous risquez d´accroître la vulnérabilité de vos applications.

Mythe nº 1 : Conformité = sécurité (applicative)

Mythe nº 1.1 : Les normes et les réglementations en vigueur sont parfaitement adaptées aux problématiques de sécurité et aux risques métier des entreprises, et ce pour une raison simple : les personnes ou les comités qui ont rédigé ces normes et réglementations comprennent les vraies menaces qui pèsent sur la sécurité métier et logicielle des entreprises.

Mythe nº 1.2 : Si votre société passe avec succès un audit de type PCI/SOX/SAS 112/..., cela signifie qu´elle répond aux critères de sécurité d´une évaluation sérieuse.

La réalité : Les normes de conformité et les exigences de sécurité sont rarement harmonisées, tout particulièrement du point de vue applicatif. Un grand nombre de normes bien connues (et bien intentionnées) ne se préoccupent pas de la sécurité applicative ou l´abordent de façon superficielle (par exemple en s´intéressant uniquement aux applications Web). Certaines normes ont été rédigées pour résoudre des problèmes très spécifiques. Ainsi, la loi Sarbanes-Oxley a été promulguée pour encadrer plus rigoureusement la production des données financières et notamment des bilans. Le fait que votre société ait obtenu la conformité SOX ne cautionne pas pour autant la stratégie qu´elle a adoptée pour protéger ses applications.

Certaines normes de conformité ont une portée tellement spécifique qu´elles se focalisent uniquement sur la sécurité des réseaux. On peut notamment citer la norme PCI DSS (Payment Card Industry Data Security Standard), qui prévoit des exigences spécifiques pour la sécurité réseau, mais qui – pour l´heure – n´aborde que très superficiellement la sécurité des applications. Les spécialistes du secteur s´accordent à dire que la sécurité doit être intégrée à chaque étape du cycle de développement logiciel. Or, ce besoin n´est pas pris en compte par ces normes, par ailleurs formulées dans un objectif louable.

Mythe nº 1.3 : Les auditeurs internes/externes comprennent bien les enjeux de sécurité logicielle et sont capables d´identifier tout problème majeur.

La réalité : La plupart des auditeurs de conformité n´ont pas ou peu d´expérience du développement logiciel. Cette réalité – renforcée par le fait que les normes laissent de côté les enjeux spécifiques à la sécurité logicielle – signifie qu´un auditeur repèrera difficilement les problèmes de sécurité logicielle, même majeurs. C´est ainsi que certaines entreprises déclarées « conformes » aux normes en vigueur peuvent se retrouver menacées par des vulnérabilités au niveau de la couche applicative.


Mythe nº 2 : « Nous n´avons pas de problèmes de sécurité logicielle. »

Mythe nº 2.1 : Nous n´avons jamais été confrontés à des brèches de sécurité majeures ; nous n´avons donc pas à nous inquiéter.

La réalité : Le fait qu´il n´existe aucune brèche connue ne peut constituer en soi un gage de sécurité. En l´absence de défaillance grave et vu le nombre impressionnants de normes de sécurité logicielle, on pourrait penser que la sécurité logicielle est sous contrôle. En réalité, une simple vulnérabilité applicative peut occasionner la création de brèches que la plupart des services informatiques sont incapables de détecter. Autre élément à ne pas perdre de vue : ce n´est pas parce qu´un système n´a pas encore subi d´attaques qu´il n´en subira pas à l´avenir. Les nouvelles technologies et l´automatisation facilitent en effet la tâche des pirates informatiques, qui peuvent s´en prendre à peu de frais à des cibles toujours plus variées. Pour conclure, n´oublions pas qu´un audit de qualité – aussi exhaustif soit-il – peut passer à côté de failles de sécurité majeures, et qu´un bilan AQ positif ne constitue pas pour autant un bon indicateur de sécurité.

Mythe nº 2.2 : Nous possédons peu d´applications Web ; la sécurité n´est donc pas un problème.

La réalité : Certes, les applications Web vous exposent à des risques importants, mais les vulnérabilités des applications « non-Web » doivent également être prises très au sérieux. Imaginez les conséquences d´une faille applicative au niveau du serveur interne (qui n´est pas en interface avec Internet) en plein traitement de données-client. Le fait de négliger la sécurité de cette application revient à penser que chaque donnée qu´elle traite est fiable. Mais la plupart du temps, ce raisonnement est malheureusement erroné, car toutes les données traitées par votre système ne sont pas fiables : des données malveillantes peuvent « passer à travers » une entité jugée fiable (une base de données, par exemple) et atteindre des codes vulnérables par des moyens totalement inattendus. Dans un environnement aux ressources limitées, certains peuvent faire ce choix pour des applications très peu critiques, ou dans lesquelles transitent uniquement des données soigneusement expurgées. En revanche, si vos applications sont essentielles aux activités de votre entreprise ou si elles traitent des données de grande valeur, le risque est très sérieux, et toute faille applicative peut vous coûter très cher.

Mythe nº 2.3 : Notre entreprise n´est pas concernée par les normes SOX/GLBA/HIPAA/etc., par conséquent, la sécurité n´est pas un enjeu majeur.

La réalité : Les vulnérabilités logicielles peuvent mettre en danger les processus métier et les données clés de l´entreprise – un enjeu qui va bien au-delà de la simple conformité. Il est nécessaire de mettre en œuvre des stratégies de sécurité logicielle pour toutes les applications appelées à jouer un rôle important en termes de confidentialité, d´intégrité ou de disponibilité.


Mythe nº 3 : Les défenses réseau suffisent à nous protéger

Mythe nº 3.1 : Les failles de sécurité logicielle sont neutralisées par les dispositifs de défense réseau (comme les routeurs ou les pare-feux) ; par conséquent, nous pouvons déjouer la plupart des attaques qui se produisent au niveau du réseau.

La réalité : Bon nombre de solutions de sécurité réseau se targuent d´être extrêmement puissantes – certaines affirment même être le remède à tous les maux. En réalité, de nombreux systèmes censés contrôler la sécurité réseau partent du principe que la couche logicielle est sécurisée, au lieu de protéger réellement le système contre les vulnérabilités logicielles. Par exemple, quand il est utilisé correctement, le protocole SSL permet d´établir un « canal privé » entre un utilisateur et une application serveur. En revanche, si l´utilisateur a des intentions malveillantes et que l´application traitant ses données est vulnérable, le protocole SSL ne suffit pas à protéger l´entreprise.
Même certains pare-feux applicatifs réputés efficaces et capables d´identifier correctement de nombreuses attaques directes telles qu´une attaque par injection de commandes SQL ou une attaque XSS (Cross Site Scripting) s´avèrent incapables de prévenir certaines vulnérabilités – et notamment les vulnérabilités intervenant au niveau des applications de logique métier, ou encore les dépassements de mémoire tampon susceptibles d´être hébergés dans le programme qui traite les données utilisateur. Sur l´ensemble du cycle de vie applicatif, le pare-feu doit constituer l´une des dernières étapes d´une stratégie de sécurité exhaustive – et non la première, ou pire, la seule.


Mythe nº 4 : La sécurité logicielle ? Quelqu´un d´autre s´en charge

Mythe nº 4.1 : Tout est déjà sous contrôle. Le responsable de la sécurité peut avoir le raisonnement suivant : « Le service de développement logiciel s´occupe de la sécurité applicative, puisqu´il revient aux développeurs de concevoir les applications. Il ne me reste plus qu´à veiller sur la sécurité des autres domaines. » De son côté, le directeur technique/DSI peut avoir le raisonnement suivant : « Le service de sécurité s´occupe de la sécurité applicative puisqu´ils sont experts en sécurité. »

La réalité : On trouve sur le marché de très bons responsables de la sécurité et d´excellents directeurs techniques ou DSI, à même d´exploiter au mieux le budget qui leur est confié et d´encadrer leurs équipes de sorte à garantir le bon fonctionnement et la sécurité des systèmes de l´entreprise. Toutefois, la sécurité logicielle est rarement bien intégrée à la mission spécifique de ces équipes. De même, il est rare que les membres de ces équipes aient reçu une formation pointue à la fois en développement logiciel et en sécurité. Pour devenir responsable de la sécurité, il faut posséder des compétences très variées – un bon responsable de la sécurité sera à la fois diplomate, à l´affût du moindre dysfonctionnement, vendeur, convaincant, capable d´exécuter un projet et de le gérer. Son parcours peut être très différent d´une personne à l´autre : technologie, réglementation, gestion, recherche ou enseignement universitaires, etc. La plupart des responsables de la sécurité comprennent très bien les concepts propres à la sécurité, mais n´ont jamais écrit de code et ignorent les risques qu´un code vulnérable peut faire courir à une entreprise. De même, les personnes chargées de diriger un service technique ou informatique ont rarement abordé les problématiques de sécurité de façon concrète. Résultat : un manque de cohésion entre ces différents services, auquel vient s´ajouter la conviction que la sécurité logicielle tient soit à l´efficacité des développeurs, soit aux compétences des personnes chargées d´assurer la sécurité réseau. Dans les faits, la sécurité logicielle dépend de ces deux catégories de personnes à la fois. La sécurité logicielle exige une collaboration spécifique et ciblée entre l´équipe qui met en place les défenses de l´entreprise et celle qui conçoit les programmes nécessaires au bon fonctionnement de l´entreprise.

Mythe nº 4.2 : Les pirates informatiques s´attaquent aux plateformes et aux applications les mieux connues ; ils ne s´en prendront pas à notre logiciel propriétaire.

La réalité : Aujourd´hui, l´économie souterraine est mature et monnayer des données volées n´a jamais été aussi « accessible ». Autrement dit, les pirates intelligents n´hésitent plus à investir beaucoup de temps, d´énergie et d´argent pour élaborer des stratégies d´attaque visant des cibles très pointues.
Ajoutez à cela la profusion d´outils permettant de « tester » à distance des interfaces applicatives communiquant avec un réseau, et vous comprendrez mieux ce qui motive les pirates informatiques à identifier les failles d´un logiciel propriétaire.


Mythe nº 5 : La théorie de la solution miracle

Mythe nº 5.1 : Un test d´intrusion suffit à détecter toutes les vulnérabilités d´un système.

Mythe nº 5.2 : Un analyseur de code source pourra déceler toutes les failles logicielles présentant un risque pour l´entreprise.

Mythe nº 5.3 : Les langages tels que Java ou C# sont sécurisés. En les utilisant, nous sommes sûrs de remédier à la plupart – voire à la totalité – des problèmes de sécurité.

Mythe nº 5.4 : En matière de sécurité, je m´occupe de la/du X, par conséquent tous les risques sont maîtrisés.

La réalité : Face à tout type de problème, il est naturel de rechercher (et d´espérer trouver) une solution unique permettant de résoudre le problème dans son intégralité. Cela peut être un outil à acquérir, un service à rémunérer, une personne à embaucher, etc. Mais la sécurité logicielle n´est pas un problème qui peut se régler aussi simplement. Prenons le cas des solutions de sécurité logicielle suivantes, très répandues :

• Le test d´intrusion : ce test potentiellement utile n´est toutefois pas capable de déceler toutes les failles majeures d´une application. De plus, le fait d´identifier et de corriger les vulnérabilités aussi tard dans le cycle de développement peut s´avérer très coûteux.
• L´analyseur de code source : cet outil constitue un composant clé de toute solution globale mais il doit être associé à d´autres processus capables de repérer les problèmes de conception et de déploiement.
• Les pare-feux applicatifs : ces outils protègent le système contre un nombre de menaces relativement faible ; en aucun cas, un pare-feu ne peut remplacer l´intégration de la sécurité au cœur même du cycle de développement logiciel.
• Les langages « sécurisés » (tels que Java et C#, entre autres) limitent certaines vulnérabilités (notamment les dépassements de mémoire tampon), mais ne protègent pas le système contre d´autres types de failles critiques.

Pour être efficace, la sécurité applicative doit être déployée à chaque étape du cycle de développement logiciel. Pour ce faire, il faut comprendre toutes les exigences de sécurité d´un système donné, prendre en compte les obligations de conformité, les enjeux de sécurité, les clauses contractuelles, le type de données traitées par l´application et enfin le risque métier. Lors de la phase de conception, il est important de vérifier la sécurité de l´architecture en créant des modèles de menaces et en suivant les principes du moindre privilège et des défenses en profondeur par exemple. En phase de développement, la formation aux concepts de sécurité est capitale et doit aller de pair avec l´analyse du code source. La phase de test doit prendre en compte les attaques générées par des outils, sans pour autant négliger la créativité du cerveau humain. En phase de déploiement, l´application doit être configurée de façon à s´exécuter en toute sécurité dans son environnement. Aucune solution ne peut couvrir l´ensemble de ces besoins. Pour déjouer les menaces, il faut faire appel à des outils de sécurité mais aussi lancer différents processus (formation, évaluation des menaces, analyse du code source). Utilisés indépendamment, ces outils et processus s´avèrent inefficaces.


Mythe nº 6 : Le fatalisme : Les stratégies de sécurité efficaces sont trop onéreuses ; je prends le risque qu´un problème survienne.

Mythe nº 6.1 : Il est impossible de mesurer la sécurité logicielle ; par conséquent, il est difficile de réaliser une étude de faisabilité.

Mythe nº 6.2 : La sécurité logicielle implique une surcharge de travail qui va paralyser mon équipe de développement – c´est un prix trop élevé à payer.

La réalité : Le parcours à suivre pour atteindre un meilleur niveau de sécurité logicielle est semé d´embûches, et le fatalisme en fait partie. Le fatalisme consiste à croire que le manque d´indicateurs métier, l´ampleur d´un problème ou les contraintes pesant sur les équipes de développement sont insurmontables. Certes, la mise en œuvre d´une stratégie de sécurité logicielle est un processus qui n´est ni simple, ni instantané, mais il est possible de procéder à des améliorations graduelles. On a notamment pu observer le développement d´initiatives axées sur la sécurité logicielle, parmi lesquelles on peut citer les suivantes :

• SAFECode (Software Assurance Forum for Excellence in Code) – Un consortium d´éditeurs logiciels de premier plan qui mettent en avant des pratiques exemplaires visant à améliorer la sécurité logicielle.
• SDL (Security Development Lifecycle) de Microsoft – L´éditeur a publié un ensemble détaillé de pratiques (dont des outils gratuits) pour accroître la sécurité des applications.
• Le gouvernement américain s´est employé à mieux délimiter les problèmes de sécurité applicative en identifiant et en supervisant les vulnérabilités logicielles, notamment par le biais de projets recensant les failles et les vulnérabilités connues, à l´instar du CVE (Common Vulnerabilities and Exposures) et du CWE (Common Weaknesses Enumeration).
• Le ministère américain de la Sécurité intérieure (DHS) a conçu un portail nommé « Build Security In » (https://buildsecurityin.us-cert.gov), ayant pour mission de recenser les pratiques d´excellence en matière de développement sécurisé et de parrainer les initiatives collaboratives mises en œuvre dans ce domaine, comme le site Open Source de Coverity qui permet d´analyser le code source (http://scan.coverity.com).

Ces projets, auxquels vient s´ajouter la volonté de certaines entreprises de partager leurs expériences dans le domaine de la sécurité applicative, ont permis d´identifier plus clairement les processus efficaces, mais aussi ceux voués à l´échec. Déjà adoptées à très grande échelle, ces méthodologies se rejoignent sur quelques points fondamentaux, à savoir la formation à la sécurité applicative, la modélisation des menaces, l´analyse du code source et les tests axés sur la sécurité. L´amélioration progressive de ces processus a permis de créer des synergies et de renforcer la sécurité des applications. De plus, certains indices laissent à penser que des normes aussi fondamentales que la PCI DSS vont davantage se focaliser sur la sécurité logicielle au fil de leur développement. Cette évolution aboutira in fine à plus d´harmonisation entre sécurité logicielle, conformité et gestion des risques. Il y a tout lieu d´espérer que dans un futur proche, les équipes chargées du développement logiciel seront en mesure de déployer des stratégies et des outils de sécurité efficaces sans pour autant sacrifier leurs budgets.


Mythe nº 7 : Le code externalisé est complètement vulnérable (ou d´une fiabilité à toute épreuve)

Mythe nº 7.1 : Les prestataires externes conçoivent des logiciels sécurisés.

Mythe nº 7.2 : Le développement externalisé ne permet pas d´obtenir des logiciels offrant une vraie « qualité de sécurité ».

La réalité : De nombreuses entreprises choisissent de confier le développement de certains de leurs produits à des prestataires externes – souvent des sociétés off-shore. Outre les difficultés inhérentes à la gestion à distance, l´externalisation du développement logiciel présente certains inconvénients. Ainsi, les sociétés doivent renoncer à contrôler intégralement certains aspects du développement, par exemple l´identité de la personne qui développe le code, ses compétences, ou encore les stratégies et les processus employés par le prestataire externe. Du fait de sa nature transactionnelle, le développement externalisé a donné naissance à deux mythes diamétralement opposés : le premier consiste à croire qu´un logiciel conçu en externe est forcément bien sécurisé ; a contrario, le second estime qu´un logiciel développé par un prestataire externe présente fatalement des vulnérabilités. Dans la pratique, la plupart des prestataires externes sont contractuellement tenus de réaliser des tests de réception sur le logiciel développé. Si le contrat ne prévoit aucun processus ou test de réception de sécurité, il est peu probable que le logiciel développé soit un programme que l´entreprise puisse déployer en toute confiance. La sécurité logicielle implique des efforts ciblés. Elle ne découle pas naturellement des processus classiques de développement logiciel, même si ce dernier est effectué par des développeurs qui respectent les standards de « qualité ». Par conséquent, même les prestataires externes qui appliquent des processus très matures et reproductibles (identifiés par les résultats de l´évaluation CMM, ou Capability Mature Model) ne conçoivent pas nécessairement des logiciels plus sécurisés. Pour résoudre ce problème, une solution consiste à inscrire des clauses touchant à sécurité dans le contrat liant l´entreprise au développeur externe. Parmi les possibilités envisageables, l´entreprise peut imposer au prestataire externe de suivre une formation initiale en sécurité logicielle, de lui fournir des exemplaires des artefacts de conception et de modélisation des menaces, ou encore l´obliger à livrer un logiciel ayant passé avec succès les tests d´analyse du code source ou d´intrusion. Certaines entreprises ont relevé ce défi haut la main : non seulement elles ont réduit les risques inhérents à l´externalisation du développement logiciel, mais ont également ajouté une dimension de sécurité à leurs processus d´audit.


Résumé

En l´absence d´indicateurs et de données ad hoc, de nombreuses idées reçues circulent au sujet de la sécurité applicative. Pourtant, certains dispositifs permettent aujourd´hui de démystifier ces idées reçues, notamment les lois sur la notification des brèches, mais aussi l´évolution des processus, des outils, de la recherche fondamentale et des formations. Ces dernières années, le secteur de la sécurité s´est transformé rapidement. Les systèmes sont désormais interconnectés, et à l´avenir, le « périmètre réseau » pourrait être amené à disparaître. La cybercriminalité est aujourd´hui mieux organisée et motivée par l´appât du gain. Il est impératif que les entreprises réexaminent à la lumière de ces changements certaines idées reçues sur la sécurité logicielle. Notre industrie est encore loin de pouvoir concevoir un logiciel entièrement exempt de vulnérabilités, mais nous avons tiré les leçons des échecs passés. Nous savons désormais que les failles logicielles constituent une menace préoccupante qui fait courir de graves risques aux entreprises. Nous savons également que la sécurité logicielle n´est pas le corollaire du développement logiciel. Et surtout, nous savons que les processus de développement peuvent – et doivent – jouer un rôle important dans l´optimisation de la sécurité logicielle.



Noter cet article (de 1 = Nul à 5 = Excellent) Valider

Dossier

Droit d’accès et comptes à privilèges

Jacques Cheminat 0 142936
Equifax, Deloitte, Uber, les récentes violations de données ont souvent des techniques de piratages différentes, mais un élément commun, obtenir l’accès à des applications critiques comme les bases de données, les bases clients, les informations bancaires. En général ces programmes sont soumis à habilitation et rattachés à des comptes à privilèges. leur protection est donc une nécessité dans un monde de plus en plus ouvert et insécurisé. Dossier publié avec le concours de Kleverware.
RSS
12



Événements SSI