Bonjour à tous.
Aujourd'hui, au lieu de parler de piratage et d'intrusion dans les systèmes comme nous le faisons
habituellement, nous allons parler de sécurité et plus précisément de la façon de sécuriser les sites Web, les applications Web, les applications
mobiles, etc.
De toute évidence, les piratages et les violations ont un impact négatif énorme sur les entreprises, de la perte de confiance
des clients aux pertes financières.
Fuites de données utilisateur, problèmes juridiques et la liste continue.
Maintenant, si vous faites une recherche rapide sur Google sur la façon de sécuriser votre site Web ou votre application,
vous allez avoir beaucoup de déchets.
J'étais en fait tellement déçu par les articles sur les appâts à clics qui n'expliquaient ni ne donnaient aucune information
utile.
La plupart d'entre eux vous ont suggéré d'utiliser des sauvegardes, des mots de passe forts et de vous assurer d'utiliser HTTPS.
Mais les sauvegardes ne sécurisent pas votre site Web, elles vous aident simplement à récupérer.
De plus, l'utilisation d'ETP crypte la communication, mais ne sécurise pas vraiment le site Web.
Le seul conseil utile était d'utiliser des mots de passe forts.
Mais la plupart des pirates ne vont pas s'asseoir et essayer de deviner le mot de passe comme vous le voyez dans les films hollywoodiens.
Ils vont s'appuyer sur les vulnérabilités et les faiblesses de votre application, et ils les exploiteront pour
y accéder, quel que soit le mot de passe que vous utilisez.
Même si vous avez un mot de passe très, très complexe, même si vous utilisez HTTPS et même si vous avez des sauvegardes, une grande partie de cela
est en fait hors de propos.
De plus, peu importe où vous avez hébergé l'application, que vous utilisiez un A. W. ou tout autre fournisseur de
cloud, et peu importe la façon dont vous déployez cette application.
Si vous utilisez Kubernetes ou si vous utilisez Docker, cela n'a pas vraiment d'importance.
C'est en fait très, très simple.
Si vous avez une application Web vulnérable, les pirates informatiques utiliseront ces vulnérabilités ou faiblesses
pour accéder à cette application.
Bref, assez de discours.
Parlons de la façon de sécuriser réellement les sites Web et les applications.
Tout d'abord, avant de commencer à en parler, il est très important de comprendre qu'il est
impossible d'atteindre une sécurité à 100 %.
Tout ce que nous essayons de faire, c'est d'améliorer la sécurité de nos applications et de nous assurer qu'elles sont aussi
sécurisées que possible.
Cela étant dit, les quatre approches suivantes vous aideront à améliorer la sécurité de vos applications, quel
que soit le type d'application et l'endroit où elles sont installées.
Comme je l'ai dit, peu importe que vous les installiez sur Amazon ou n'importe où ailleurs sur un WIC
ou autre chose, et peu importe comment vous le déployez si vous utilisez Docker, etc.
La première chose à faire est donc de vous assurer que vous écrivez du code sécurisé de cette façon.
Votre application est conçue dès le départ pour être sécurisée et pour ne pas introduire de bogues ou de vulnérabilités pouvant
être exploités par des pirates pour y accéder.
Maintenant, ce serait formidable si vous pouviez le faire, mais le problème est que c'est plus facile à dire qu'à
faire parce que les développeurs doivent être éduqués et apprendre les méthodes que les pirates utilisent pour exploiter les systèmes et y
accéder.
Et même si vous faites cela, la plupart du temps, les développeurs s'appuient sur des bibliothèques tierces et l'ensemble de l'application peut
être écrit par quelqu'un d'autre.
Par conséquent, vous ne pouvez tout simplement pas écrire de code sécurisé car vous n'êtes pas réellement l'auteur ou le
développeur de cette application.
Ce qui m'amène au deuxième point.
Révision du code.
C'est en fait très bien, même si vous avez écrit l'application vous-même, et même si vous vous êtes
assuré d'écrire du code sécurisé, c'est une très bonne idée de faire réviser ce code par d'autres développeurs ou une
autre équipe.
Juste au cas où les développeurs écrivent que l'application manque quelque chose ou oublie quelque chose, alors elle sera
détectée au stade de la révision.
De plus, si vous utilisez le code écrit par d'autres développeurs ou des bibliothèques tierces, là encore, une révision
de code résoudra ce problème car vous pouvez réviser et tout.
Et encore une fois, c'est vraiment très bien parce que vous examinez chaque
ligne et assurez-vous que rien n'est vulnérable ou ne permettra aux pirates d'exploiter votre application et d'y accéder.
Le principal inconvénient ici est que si vous avez une grande base de code, cela peut prendre beaucoup
de temps et peut également être très coûteux.
La troisième approche, qui est très essentielle, à mon avis, consiste à faire un test d'intrusion.
Dans un test de plume.
En gros, vous engagez une équipe de hackers éthiques pour essayer de pirater votre application.
Ces pirates éthiques aborderont votre application de la même manière que les pirates Black Hat.
Ils vont essayer de rassembler autant d'informations que possible et découvrir toutes les faiblesses et vulnérabilités et voir
s'ils peuvent les exploiter pour y accéder.
À la fin, lorsqu'ils auront terminé, ils vous donneront un rapport détaillé de tout ce qu'ils ont
trouvé afin que vous puissiez le transmettre à vos développeurs et corriger les vulnérabilités qu'ils découvrent.
Le principal avantage de cette méthode est que vous pouvez tester des surfaces d'attaque que vous ne pouvez pas tester
avec d'autres méthodes, telles que vos serveurs qui exécutent votre application Web et le maillon le plus faible, à savoir
les employés.
Ainsi, ces pirates, les pirates éthiques, peuvent même utiliser l'ingénierie sociale et l'enchaîner avec d'autres attaques ou
vulnérabilités plus simples qu'ils pourraient trouver sur votre système pour voir s'ils peuvent les utiliser pour
y accéder.
Les inconvénients ici sont que cela pourrait être un peu cher et que ce n'est pas à l'épreuve du temps.
Ce que je veux dire, c'est que si vous faites tester votre application aujourd'hui par de très bons
pirates éthiques, puis assurez-vous de corriger chaque vulnérabilité qu'ils trouvent, cela signifie seulement que votre application Web est sécurisée
aujourd'hui.
Cela ne garantit pas qu'il restera sécurisé pour le mois prochain ou l'année prochaine, car chaque modification
que vous apportez, chaque fonctionnalité que vous poussez ou même chaque bogue d'affichage que vous corrigez peut introduire
d'autres bogues ou faiblesses de sécurité qui peuvent ensuite être utilisés pour pirater votre application.
Non seulement cela, mais encore une fois si vous mettez à jour à nouveau des logiciels ou des plugins
tiers, tout cela pourrait introduire des vulnérabilités, et un test ne pourra pas détecter cela parce que vous ne faites
que les Panthers aujourd'hui, et ces futurs changements sont ne sera pas testé.
La quatrième approche, qui peut réellement résoudre ce problème, consiste à avoir un programme de prime aux bogues.
Un programme de bug bounty est essentiellement une invitation à tous les pirates informatiques éthiques du monde entier à tester
votre application et à soumettre leurs conclusions.
Et vous ne paieriez que pour des bogues valides ou des rapports valides.
Le principal avantage est ici, comme vous l'avez deviné, probablement maintenant, que vous faites tester
votre application par un grand nombre de pirates, donc les chances qu'ils trouvent des vulnérabilités sont plus élevées.
Et c'est en fait à l'épreuve du temps car tant que vous avez cette liste de primes de bogues en direct, ces pirates
continueront toujours à tester votre application et vous les motivez avec des primes.
Donc, cela pourrait être n'importe quoi, d'un T-shirt à des récompenses monétaires.
Pour s'assurer qu'ils vont réellement continuer à tester votre application.
Ainsi, même si vous proposez de nouveaux changements, de nouvelles fonctionnalités ou des mises à jour, cela n'a
pas vraiment d'importance car les pirates continueront de tester votre application dans l'espoir de trouver des bogues et d'obtenir des primes pour leurs découvertes.
C'est pourquoi les grandes entreprises comme Facebook et Google utilisent ces programmes de primes aux bogues, même s'ils
suivent toutes les autres approches.
Comme je l'ai dit, ils l'utilisent toujours pour s'assurer que leurs systèmes sont toujours aussi sécurisés que possible et aussi
exempts de bogues que possible.
Les inconvénients ici sont, tout d'abord, qu'il est difficile de garantir que toutes les surfaces d'attaque sont couvertes.
Et deuxièmement, beaucoup d'entreprises n'ont pas la portée que Google et Facebook ont, donc elles ne peuvent pas vraiment annoncer
leurs primes de bogues aussi bien que les grandes entreprises le font.
Ils ne peuvent pas amener beaucoup de pirates éthiques à tester leur site Web.
Il leur est difficile de créer ces programmes de primes de bogues et de valider les rapports soumis.
Mais cela est résolu par les plates-formes de bug bounty que nous avons ces jours-ci, telles que bug bounty, dotcom
et les autres plates-formes.
Bug Bounty est en fait une société sœur de cette sécurité.
Mon avis est donc peut-être un peu biaisé, mais je suis presque sûr que nos prix sont les plus compétitifs et que
nous offrons le même service.
Donc de toute façon, je suis inclus dans tout là-bas.
Vous avez le choix.
Vous pouvez vérifier ce que vous voulez, et je suis désolé si je vous ai vraiment confondu avec l'approche de l'automne.
Est-ce que je viens de le mentionner, mais à mon avis, idéalement, vous voudriez suivre toutes ces quatre approches,
si vous le pouvez.
Cela pourrait être assez cher.
C'est pourquoi beaucoup d'entreprises ne le font pas.
Et ils feraient des compromis et n'iraient qu'avec trois et quatre.
Donc, ils ne feront qu'un test de patch et auront un programme de prime aux bogues.
Et puis d'autres entreprises font parfois encore plus de compromis.
Et choisissez l'un des deux, soit un programme de bug bounty, soit un test d'intrusion.
À mon avis, un test d'intrusion ne remplace pas un programme de bug bounty et vice versa.
Je vous recommanderais de faire les deux car, comme je l'ai dit, chacun d'eux a ses avantages
et ses inconvénients.
Mais si vous ne pouvez vraiment pas faire les deux, faites au moins l'un d'eux comme le strict minimum.
En tant que propriétaire de site Web ou propriétaire d'application, vous êtes responsable des données utilisateur avec lesquelles les utilisateurs vous font
confiance, et vous devez donc faire au moins le strict minimum pour essayer de vous assurer
que leurs données sont traitées en toute sécurité.