DE{CODE} : Protégez vos sites WordPress face à une augmentation des cyberattaques mondiales

Rejoignez les experts de WP Engine et Cloudflare pour cette session spécifique à la sécurité sur la façon de verrouiller vos sites Web. La discussion met en évidence les tendances récentes en matière de cyberattaques ainsi que des exemples spécifiques de la manière dont WP Engine protège vos sites. Les développeurs repartiront avec une liste de contrôle claire des étapes à suivre pour sécuriser leurs sites.

Diapositives de la session

Transcription du texte intégral

ERIC JONES : Bienvenue sur DE{CODE}, et merci d'avoir rejoint ce qui promet d'être une session en petits groupes incroyable. Je m'appelle Eric Jones et je suis le vice-président du marketing d'entreprise chez WP Engine. Je ne pourrais pas être plus enthousiaste à l'idée de modérer cette discussion aujourd'hui entre Joe Sullivan, le directeur de la sécurité de Cloudflare, et Brent Stackhouse, le vice-président de la sécurité de WP Engine, qui ont à eux deux des décennies d'expérience dans le domaine de la sécurité.

Notre discussion, Garder vos sites WordPress en sécurité face à une augmentation des attaques mondiales de cybersécurité, ne pourrait pas être plus opportune étant donné que les cyberattaques ne sont pas seulement en augmentation, mais qu'elles atteignent des sommets sans précédent. Joe, pourquoi ne pas commencer par vous ? J'aimerais entendre, d'un point de vue global et global, quelles tendances vous observez dans le paysage de la cybersécurité.

JOE SULLIVAN : Bien sûr. Je suis heureux d'intervenir. Merci de m'avoir invité à cette conversation. J'ai aussi vraiment hâte d'y être. Je pense qu'il y a deux mégatendances dans le monde de la sécurité en ce moment. Premièrement, c'est beaucoup plus important aux yeux du monde.

Donc, avant d'aborder l'aspect technique et les défis auxquels nous sommes confrontés jour après jour, il vaut la peine de prendre un moment pour voir à quel point le monde de la sécurité a évolué depuis que Brent et moi avons commencé dans cette profession, comme vous avez dit, il y a des décennies.

La sécurité n'est plus une équipe ou un concept qui reste dans le coin d'une organisation. Il est au cœur de tout ce que nous faisons. Les PDG sont tenus responsables. Les conseils d'administration posent des questions difficiles. Les capital-risqueurs ne contribueront pas s'ils ne voient pas le bon niveau d'investissement.

Et, plus important encore, nos clients, consommateurs et acheteurs commerciaux de nos produits exigent beaucoup plus de nous. Et pour moi, c'est la tendance la plus importante et la raison pour laquelle nous avons cette conversation. Cela compte pour chaque développeur dans tous les aspects de son travail.

Donc, en ce qui concerne ce qui se passe réellement dans le monde de la sécurité, cela ne devient pas plus facile. Et les défis ne cessent de nous tomber dessus. Si vous faites attention aux gros titres, vous avez vu ces derniers temps la montée des ransomwares. C'est vraiment effrayant.

Les ransomwares ont changé la donne en termes de sécurité, car ils sont passés du vol de données ou de l'exposition de quelque chose au monde à la fermeture de votre entreprise. Et donc tout le concept de l'importance de la sécurité a été amplifié par ce risque, l'idée que nous pourrions nous réveiller le matin et ne pas pouvoir allumer nos ordinateurs portables, ne pas faire fonctionner notre site Web. C'est vraiment effrayant.

Les choses géopolitiques commencent également à nous affecter tous. La situation en Ukraine ne se limite pas au monde physique. C'est fortement dans le contexte cybernétique en ce moment. Et ça déborde pour avoir un impact sur le reste d'entre nous. Ainsi, les événements géopolitiques qui se produisent dans le monde physique ont des implications techniques pour ceux d'entre nous qui essaient d'exploiter des entreprises sur Internet.

Et je pense que la troisième chose que je mentionnerais d'un point de vue technique est que nous ne vivons pas dans des mondes de notre propre code. Nous vivons dans des mondes qui sont un amalgame de logiciels et de codes qui s'unissent pour représenter une organisation.

Et donc, en sécurité, nous utilisons le terme chaîne d'approvisionnement pour parler de tous ces autres codes et autres applications et de tout ce qui fait partie de notre identité en tant qu'entreprise. Ainsi, par exemple, lorsqu'il y a eu récemment des histoires sur la compromission d'Okta, il ne s'agissait pas seulement de savoir si Okta était compromis. Il s'agissait de savoir si mon entreprise et toutes les autres entreprises qui utilisent Okta sont compromises.

Et mes clients ne se souciaient pas d'Okta. Ils se souciaient de leur utilisation de nous, et quels contrôles avions-nous mis en place pour atténuer le risque qu'Okta soit compromis ? Il se passe donc beaucoup de choses en ce moment. Et c'est un bon moment pour avoir cette conversation.

ERIC JONES : Joe, juste comme question de suivi, comment pensez-vous de la hiérarchisation de tous ces défis spécifiques que vous avez et que chaque organisation de sécurité a ?

JOE SULLIVAN : Bien sûr. Je pense que c'est la question ultime. Si nous avions un budget illimité et un nombre illimité de personnes capables de faire le travail, nous pourrions tout faire. Mais ce n'est pas la réalité dans n'importe quelle organisation à n'importe quel stade de son développement.

Nous sommes donc toujours dans le processus de priorisation. Et donc ce que je dirais, c'est que vous devez d'abord prioriser les bases. Il est choquant de constater qu'un grand pourcentage des compromis proviennent d'échecs dans les bases.

En tant que professionnels de la sécurité, nous aimons aller creuser dans cette attaque zero-day ou O-day et regarder cette chose vraiment compliquée. Mais 90 % du temps, les compromis proviennent d'e-mails de phishing ou de quelqu'un qui choisit d'utiliser le même mot de passe que celui utilisé sur un site Web personnel qui a été compromis et qui n'a pas activé l'authentification multifacteur.

La plupart du temps, nous avons en fait les outils pour bien faire les bases, mais nous ne prenons pas le temps de les mettre en œuvre.

ERIC JONES : Oui, je pense que vous touchez à un point crucial en matière de sécurité, n'est-ce pas ? Que c'est quelque chose dont nous sommes tous responsables. C'est une responsabilité partagée dans toute l'organisation. Il ne vit pas seulement au sein de l'équipe de sécurité. Il vit avec chaque employé d'une entreprise particulière.

Brent, pour vous, d'un point de vue WordPress, qu'est-ce qui est pareil, qu'est-ce qui est différent dans WordPress, et quels sont certains des plus grands points de vulnérabilité que vous voyez dans le paysage ?

BRENT STACKHOUSE : Merci, Eric, et merci de m'avoir invité. Appréciez le temps de partage avec Joe. Il sait beaucoup de choses. Nous avons fait le tour du pâté de maisons plusieurs fois. C'est donc fascinant.

WordPress à bien des égards - les nouvelles sont généralement bonnes dans le sens où WordPress Core se différencie de tous les plugins et thèmes et autres éléments de l'écosystème WordPress. WordPress Core continue d'être robuste et résistant aux attaques courantes.

Ainsi, WordPress lui-même est une bonne plate-forme stable et solide que les clients devraient généralement se sentir à l'aise d'utiliser dans à peu près n'importe quel contexte. Le défi se situe principalement du côté des plugins, où wordpress.org ou ces développeurs principaux n'ont généralement rien à voir avec la plupart des plugins et des thèmes.

Et la variabilité de la qualité du code, similaire aux applications que vous obtiendrez dans le Play Store de Google ou quelque chose comme ça, celles-ci ne sont pas écrites par, comme je viens de le dire, Google. Ils ne sont pas écrits par WordPress, ces plugins et thèmes et cela peut être n'importe quoi, d'un seul développeur à une équipe. L'empreinte de ces plugins ou thèmes peut être très petite à très grande. Ils peuvent avoir une bonne histoire de patcher les choses rapidement ou non.

Et donc ça dépend. Ainsi, à mesure que WordPress gagne en popularité et que l'écosystème gagne en popularité, vous pouvez supposer que les attaquants continueront d'intensifier leurs efforts parce qu'ils vont là où se trouve l'argent, de la même manière que Windows a plus de logiciels malveillants que les Mac en général. C'est parce que c'est là que se trouve l'empreinte, et c'est là que se trouve l'argent.

Donc, WordPress n'est pas différent, et à mesure qu'il gagne en popularité, vous pouvez vous attendre à ce que les attaquants continuent à faire ce qu'il fait. La bonne nouvelle est que, par rapport au moment où j'ai lancé le moteur WP il y a quatre ans, l'écosystème est largement plus sain.

Les développeurs de plugins, les développeurs de thèmes sont plus conscients qu'ils vont obtenir des contributions de chercheurs en sécurité ou d'autres personnes notant des vulnérabilités. Et la plupart d'entre eux construisent ce muscle de manière responsable afin de pouvoir contourner les patchs très, très rapidement.

Les choses sont donc bien meilleures qu'avant. Il y a quatre ans, de nombreux développeurs étaient surpris lorsque des vulnérabilités se produisaient et ils n'étaient pas vraiment rapides ou capables de répondre aux besoins de leurs clients en termes de correctifs réguliers.

En tant que consommateurs de technologie, nous sommes tous habitués, entre guillemets, au "Patch Tuesday" ou à nos mises à jour régulières d'Apple, etc. Nous ne sommes donc pas surpris des vulnérabilités. Nous serions cependant très surpris si ce fournisseur ne corrigeait pas quelque chose de manière responsable et rapide.

Donc, l'écosystème WordPress est en général plus sain qu'il ne l'était, je pense, il y a quatre ans. Encore une fois, WordPress Core est génial, mais je pense que les plugins et les thèmes suivent généralement le rythme. C'est donc plutôt positif.

ERIC JONES : Juste pour double-cliquer sur quelque chose que vous avez dit à propos de WordPress Core, qu'est-ce que la nature même des logiciels open source qui aide peut-être à résoudre ce problème de sécurité ? Parce que je pense que c'est l'une de ces idées fausses et mythes qui circulent selon lesquels, d'une manière ou d'une autre, les logiciels open source ne sont pas fondamentalement sécurisés.

BRENT STACKHOUSE : Eh bien, c'est une excellente question. Et je serais intéressé par les réflexions de Joe à ce sujet. Et je ne veux pas te faire de reproches, Eric, mais je suis assez vieux. J'ai vu ce que nous entendons par open source changer un peu au fil du temps.

L'open source à l'époque était des projets très connus comme Apache, ou, disons, OpenSSH, ou, disons, Linux, et des choses comme ça et donc quand nous disons open source à l'époque, c'est ce que nous étions généralement se référant à.

Et, oui, il y avait beaucoup de projets secondaires, tertiaires, peu importe les petits projets qui n'étaient pas aussi bien entretenus, etc. d'autre peut saisir.

Vous parlez de bibliothèques, de très petits codes dont tout le monde pourrait dire, oh, qui a l'air génial en fonction de ses fonctionnalités, que nous allons incorporer cela. Et je parlerai un peu plus tard comme Joe y a fait allusion avec les problèmes de chaîne d'approvisionnement. Je parlerai un peu plus tard des défis spécifiques aux développeurs en termes d'atténuation des risques de la chaîne d'approvisionnement.

Parce que l'open source - Je repense à votre question, Eric, à propos de WordPress. C'est super que la source soit là-bas. Beaucoup de gens le regardent. Je pense que c'est aussi vrai à l'époque avec Apache et des choses comme ça. Tout ce qui est utilisé à grande échelle fera l'objet d'un examen minutieux de la part des bons comme des méchants, et je pense que c'est une bonne chose. La sécurité par l'obscurité n'a jamais été une bonne pratique. Et donc avoir le code là-bas est génial.

Mais open source équivalant à une meilleure sécurité que fermé ou vice versa est une question difficile à répondre. Parce qu'ils sont littéralement des pommes et des oranges. Je pense que WordPress en tant qu'équipe a fait un excellent travail en utilisant d'autres intrants que sa propre intelligence, comme l'utilisation d'un programme de primes de bogues. WordPress Core le fait depuis des années. Je pense que c'est intelligent.

Ils ont sans aucun doute des chercheurs non affiliés qui leur envoient régulièrement leurs découvertes. Et les équipes intelligentes prennent ces informations et font ce qu'il faut. Je suis sûr qu'ils se testent eux-mêmes, etc. Nous faisons donc des choses similaires chez WP Engine, mais c'est en quelque sorte la norme pour le cours.

Joe, des idées à ce sujet ? Désolé de prendre le relais, Eric, mais–

ERIC JONES : Non, c'est parfait.

JOE SULLIVAN : Je pense que vous avez beaucoup touché les points forts. Quand je pense à un logiciel open source - quand je pense à un logiciel de n'importe quelle source, je pense que nous devons l'évaluer avant de le mettre dans notre environnement. Et parfois, un logiciel open source sera le meilleur choix que quelque chose de propriétaire. Parce que tu sais quoi ? La lumière du soleil tue l'infection.

Et ce que nous avons avec beaucoup de logiciels open source, c'est que beaucoup d'autres personnes le regardent également. Je pense que c'est quelque chose dans le monde de la sécurité en général que nous ne faisons pas assez bien, c'est que nous sommes tous assis dans nos petites équipes et nos petits coins, et nous essayons de tout résoudre nous-mêmes.

Impliquer la communauté est une bonne chose. La transparence et le dialogue sur les risques liés à des logiciels particuliers sont une bonne chose. Et nous nous améliorons. Votre exemple de programme de primes aux bogues est un autre moyen d'apporter de la transparence et d'inviter des tiers à faire des trous.

Les logiciels open source attirent de nombreuses personnes lorsqu'il s'agit des logiciels open source les plus utilisés et les plus importants. Mais de la même manière, je ne voudrais pas simplement récupérer du code de GitHub et le déposer dans mon produit sans vraiment l'examiner.

Je dirais également que vous devez faire preuve de la même prudence lorsque vous achetez une licence pour un logiciel propriétaire. Vous devez toujours regarder qui le fabrique, quelles pratiques ont-ils et quelle est sa robustesse.

BRENT STACKHOUSE : Ouais, il s'agit en grande partie – et c'est un terme de nerd à risque – mais d'assurance. Quelle assurance pouvons-nous obtenir pour tout ce que nous faisons d'un point de vue technique quant à la sécurité une fois que nous avons fait A, B, C. Et beaucoup d'assurances, selon la situation avec une source fermée, c'est plus difficile à obtenir.

En open source, vous pouvez avoir une meilleure idée plus facilement de qui a fait quoi pour vérifier le code. C'est un peu plus délicat avec une source fermée. Vous devez utiliser des entrées indirectes qui montrent que cette entreprise a eu de bonnes pratiques de sécurité au fil du temps, etc.

Mais, oui, obtenir des assurances est en fin de compte ce que vous essayez de faire lorsque vous déployez, en utilisant n'importe quelle technologie en général. Merci.

ERIC JONES : Donc, pour les développeurs qui sont là-bas, quelles sont ces assurances spécifiques que vous recherchez tous les deux dans les entreprises ? Si ces projets ou logiciels ont ces éléments, vous les considérez alors comme bons, un peu plus sûrs qu'ils ne le seraient autrement.

BRENT STACKHOUSE : Voulez-vous une réponse WordPress ? Je vais laisser partir Joe si vous voulez commencer en général.

ERIC JONES : Oui, Joe, si vous pouviez peut-être fournir une perspective large, et ensuite, Brent, vous pouvez fournir la perspective WordPress plus spécifique.

JOE SULLIVAN : Oui, donc, d'où je suis, je réfléchis à cette question en tant qu'acheteur et en tant que vendeur, car je travaille chez Cloudflare, où les gens implémentent nos produits. Et la question numéro un que tout client Cloudflare se pose avant de mettre en œuvre Cloudflare est la suivante : dois-je faire confiance à Cloudflare ? Parce que nous sommes assis devant toute leur entreprise. Et c'est un endroit vraiment risqué de mettre quelqu'un à moins que vous ne lui fassiez confiance.

Mais moi aussi, parce que nous grandissons et que nous devons développer nos produits, nous comptons également sur des tiers. Et donc je suis le destinataire des questions difficiles, et je suis le demandeur des questions difficiles.

Et, écoutez, aucun d'entre nous n'a le temps d'aller ou les ressources pour aller auditer chaque fois que nous allons travailler avec un tiers. Nous n'avons pas assez d'équipes. Nous n'avons pas les compétences pour. Nous commençons donc par les certifications de sécurité en tant que concept qui compte ici.

Quand je dis certifications, je veux dire des choses comme un SOC 2, un SOC 2 Type II comme WP Engine, ou l'ISO 27001, ou PCI. Lorsque vous entendez ces mots et certifications, ce que vous devriez penser, c'est qu'un tiers a utilisé un ensemble de normes reconnues pour entrer et auditer cette entreprise et évaluer si elle respectait tous les contrôles pour ce domaine.

Et donc chacun de nous– Cloudflare a un rapport SOC 2 Type II que nous pouvons partager. WP Engine a un rapport SOC 2 Type II que nous pouvons partager. Et la bonne chose à propos de quand je dis Type II, cela signifie que ce n'était pas seulement une vérification ponctuelle. C'était une longue période de temps.

Ainsi, par exemple, avec notre SOC 2 Type II, cela signifie qu'au cours de la dernière année, à tout moment pendant cette période pour laquelle cette certification existe, nous étions en conformité avec ces contrôles de sécurité minimaux. C'est souvent suffisant pour un client. Comme, oh, cette société a un SOC 2 Type II. OK, je vais leur faire confiance.

Mais ensuite, vous voudrez peut-être creuser un peu plus en fonction de votre implémentation spécifique. Ainsi, lorsque je pense à acheter un produit, je ne pense pas seulement à la qualité du code, mais à la façon dont il s'intègre à mon environnement.

Et donc quelque chose qui compte beaucoup pour moi, c'est l'authentification. Puis-je intégrer cela à mon authentification unique afin de pouvoir gérer qui, à l'intérieur de mon organisation et à l'extérieur de mon organisation, y a accès ? Parce que c'est de là, comme je l'ai dit plus tôt, que vient un grand pourcentage des problèmes de sécurité.

Vous voulez donc choisir des produits comme WP Engine, où vous pouvez l'intégrer à votre SSO et laisser la sécurité passer par l'outillage sans que vous ayez à faire beaucoup de travail pratique. Donc, pour moi, ce sont des certifications plus la combinaison de tout ce que vous voulez pour votre environnement spécifique.

ERIC JONES : Et, Brent, pour vous remettre la question, comment pensez-vous de cela dans un contexte WordPress ?

BRENT STACKHOUSE : Oui, je pense que c'est génial. Lorsque les gens envisagent d'étendre l'écosystème WordPress, pour ainsi dire, en utilisant des plugins et des thèmes, quelques éléments à rechercher, même dans un contexte commercial ou une couche commerciale, sont la popularité de ce morceau de code, plugin ou thème? Et puis-je voir dans leur journal des modifications qu'ils mettent à jour régulièrement, y compris pour les mises à jour de sécurité ?

Ce sont des mesures ou des intrants très qualitatifs, mais ils sont toujours pertinents. En règle générale, les développeurs de plugins ou les développeurs de thèmes qui ont une grande empreinte - ils ont beaucoup de clients - ils ont quelque chose à perdre et à gagner, pour ainsi dire, en entretenant bien ou mal leur code, selon la manière dont vous veux retourner ça. Et donc, simplement choisir les plus populaires pour tout ce dont vous avez besoin est généralement une bonne pratique.

Au niveau du développeur, vous pouvez appliquer plus de contrôle, pour ainsi dire. Vous pouvez utiliser des outils de sécurité d'application statique pour un plugin donné. Êtes-vous susceptible de trouver quelque chose qu'un autre chercheur en sécurité n'a pas ? Peut-être pas, mais c'est toujours une bonne idée d'exécuter ces choses quel que soit votre outillage. Et il existe de nombreux outils gratuits open source ou même des outils commerciaux avec des licences très peu coûteuses ou gratuites qui peuvent vous permettre d'obtenir une meilleure assurance sur le code que vous utilisez dans votre environnement.

Une chose que Joe a abordée et dont je vais vous parler un peu aussi, c'est que WP Engine est également à la fois un consommateur de code et un producteur et nous sommes donc également un fournisseur de services et très préoccupés par l'intégrité de notre efforts de développement de bout en bout. Et c'est un défi permanent.

Ainsi, l'une des choses pour nos développeurs qui gèrent des sites WordPress est qu'ils doivent être conscients, espérons-le, du contexte de risque de leur organisation. Dans quelle verticale se situent-ils, par exemple ? Quel est le degré de tolérance de l'organisation face aux mauvaises choses qui se produisent ? Certains secteurs ou organisations sont beaucoup plus sensibles à des choses comme les attaques DDoS, etc.

Donc, en pensant à cela et en codant potentiellement pour ces choses, vous ne pouvez pas coder pour DDoS, mais vous pouvez certainement en être conscient et le mettre en évidence. C'est très important pour, je pense, que les développeurs fassent ce qu'il faut.

ERIC JONES : Changeons un peu de vitesse, et dans le but d'essayer de fournir des recommandations très spécifiques, Joe, du point de vue de la sécurité de haut niveau, que recommanderiez-vous aux propriétaires de sites Web pour renforcer leur sécurité ?

JOE SULLIVAN : Oui, d'après ce que j'en pense, une once de prévention vaut mieux que guérir. Et, dans le contexte de la sécurité, cela signifie choisir les bons outils et plates-formes que vous allez utiliser avant de commencer plutôt que d'essayer de construire quelque chose, et maintenant voyons comment nous pouvons démarrer la sécurité en plus.

Ainsi, lorsque vous sélectionnez des plates-formes, lorsque vous sélectionnez des outils, lorsque vous sélectionnez du code, vous voulez y penser en pensant à la sécurité dès le départ. Et donc, comme je l'ai dit, si vous pouvez faire en sorte que la sécurité se produise automatiquement grâce aux outils que vous choisissez, vous serez dans une bien meilleure position que si vous deviez embaucher des gens pour venir à côté et faire un un tas d'audits, puis essayez de tout réparer pendant que le navire navigue dans l'océan.

Vous ne pouvez pas le patcher de cette façon. Et donc, pour moi, je cherche toujours, qu'est-ce que je peux sortir de la boîte du point de vue de la sécurité ? Quels sont les paramètres qui sont là pour moi? Et si je prends les bases de la sécurité, je pense qu'il n'y a en fait que quelques domaines.

Le numéro un, pour moi, est toujours cette gestion des identités et des accès. C'est pourquoi j'ai parlé de la possibilité d'intégrer l'authentification unique dès le départ. Si je démarrais une entreprise, je choisirais en premier lieu la bonne configuration d'authentification unique qui évoluera avec mon organisation. Et j'essaierais toujours de choisir des produits qui s'y intégreraient.

La deuxième chose à laquelle je penserais est, OK, je vais avoir un tas de code face à Internet. Comment résister aux attaques d'internet ? Dois-je me fier à mon… Brent a mentionné les attaques par déni de service.

Dois-je trouver personnellement comment avoir des équilibreurs de charge et gérer tout cela et acheter des produits comme Cloudflare ? Ou est-il intégré à une plate-forme que j'achète pour ne pas avoir à penser à la sécurité. Je sais que c'est déjà intégré, et ainsi de suite. Je passerais donc méthodiquement en revue mes employés et la gestion des identités et des accès, le code accessible sur Internet.

Et puis comme le troisième pilier est probablement - dont nous ne parlons pas vraiment ici - est, comment configurer les ordinateurs portables et des choses comme ça ?

ERIC JONES : Et, Brent, je vais peut-être vous demander, quelles sont les choses spécifiques auxquelles les développeurs WordPress devraient penser pour créer les sites les plus sécurisés possibles ?

BRENT STACKHOUSE : Oui, ma première réponse est que c'est intéressant. Une grande partie de ce dont nous parlons est une décision concernant le moment de construire ou d'acheter. Allez-vous créer vos propres plugins et tout ce que vous voulez faire pour étendre votre écosystème WordPress ? Ou allez-vous acheter pour ainsi dire même si c'est gratuit ?

Mais cela s'applique, je pense, à Joe et moi aussi, dans le sens où nous consommons le code d'autres personnes via GitHub ou n'importe quel mécanisme et nous pourrions éventuellement embaucher des développeurs et faire tout cela à partir de zéro. Ou nous pouvons utiliser quelque chose que quelqu'un d'autre a déjà fait.

Et pourquoi recréer la roue quand ce n'est pas nécessaire ? Mais alors, comment s'assurer que le code que l'on utilise est en bon état ? Donc, revenons à WordPress en particulier, je pense qu'il y a plusieurs choses - c'est probablement du bon sens pour un public de développeurs, mais nous le dirons quand même. Lorsque vous codez, codez en toute sécurité, c'est-à-dire sachez ce que vous essayez de faire. Essayez de délimiter ce que vous essayez de faire en termes de vos fonctions, toutes ces sortes de choses.

Mais gardez à l'esprit le Top 10 de l'OWASP. Le Top 10 de l'OWASP est probablement bien connu de notre public. Mais, encore une fois, les bases sont importantes, comme Joe y a fait allusion plus tôt, et donc les bases pour les développeurs incluent certainement le Top 10 de l'OWASP.

Et puis utilisez l'un de ces outils de sécurité d'application statique que j'ai mentionnés qui est très bon pré-déployé ou pendant que vous déployez. Vous pouvez le faire automatiquement, pour ainsi dire. Et assurez-vous que le code que vous envoyez là-bas est en assez bon état et qu'il n'y a pas de vulnérabilités évidentes connues avec votre propre code si vous développez du code personnalisé.

La troisième chose est liée au problème de la chaîne d'approvisionnement dont nous avons parlé. Et GitHub a des fonctions gratuites qui peuvent réellement vous dire quand vos dépendances en amont ont des vulnérabilités connues. Ainsi, Dependabot, un bot de dépendance, est une excellente chose fournie par GitHub, et vous devez absolument l'activer sur vos repos. Et il peut en fait créer des PR automatiquement. Et ensuite, vous aurez la possibilité de fusionner cela si vous pensez que vous en avez besoin pour que vos dépendances en amont n'aient au moins aucune vulnérabilité connue.

Vraisemblablement, tout le code a des bogues même lorsque vous l'expédiez et il y a probablement un sous-ensemble de bogues de sécurité, mais au moins nous devons éviter les défis évidents auxquels Joe a fait allusion plus tôt. Nous ne voulons pas entrer dans les journaux parce que nous manquons l'évidence. Comme, hé, vous devriez patcher les choses. Donc, oui, ce sont trois choses que je pense que les développeurs pourraient garder à l'esprit pour se tenir à l'écart du feu, pour ainsi dire.

ERIC JONES: Je suppose que la question pour vous deux est, quelles sont les choses que vous voyez arriver et qui ne sont pas tout à fait sur le radar en ce moment? Et quelles sont les choses auxquelles les gens, les développeurs, les propriétaires de sites Web devraient penser et qu'ils ne pensent pas en ce moment ? Et c'est une question ouverte pour l'un ou l'autre d'entre vous.

BRENT STACKHOUSE: Eh bien, oui, je veux intervenir parce que Joe a répondu à Okta plus tôt. Alors ce groupe particulier… c'est intéressant. Nous l'avons donc déjà vu. Donc, je ne peux même pas dire que c'est presque en train de s'effondrer.

Mais le groupe qui a fait exploser Okta et aussi d'autres grands noms qu'on n'a pas besoin de citer sur ce podcast ou cette interview forcément, ils utilisent surtout des techniques d'ingénierie sociale très, très intéressantes, des attaques pas très techniques du tout.

Et donc peut-être que les développeurs ne sont pas sensibles à ce type d'attaque. Cela dépend de l'organisation et de la place de ce développeur. Mais il est certain que toute personne agissant en tant que personnel informatique ou personne ayant accès aux actifs, pour ainsi dire, pour une organisation donnée pourrait très bien être la cible d'attaques d'ingénierie sociale.

C'est donc quelque chose dont nous n'aimons pas parler parce que nous ne pouvons pas simplement le réparer techniquement. Mais les humains continuent honnêtement d'être le point faible. Passer par la porte d'entrée comme nous l'appelons, c'est-à-dire une attaque externe, c'est souvent techniquement plus difficile et plus de travail pour les attaquants. Et parfois, ou souvent, ils subiront des attaques d'ingénierie sociale. Le phishing est toujours très, très efficace, quel que soit le support.

Je pense donc que c'est quelque chose qui s'avère être encore un défi. Et les organisations ne consacrent probablement pas autant de temps à cela qu'elles le devraient.

JOE SULLIVAN : Oui, je pense qu'une autre façon de dire ce que Brent a dit d'une voix légèrement différente est que je ne veux pas que les développeurs passent beaucoup de temps avec une boule de cristal, essayant d'anticiper le prochain problème de sécurité. Il est plus important de bien maîtriser les bases.

Et ces bases prendront en charge la majeure partie de la prochaine grande chose, quelle qu'elle soit. Et à titre d'exemple, j'ai mentionné qu'il y a eu un changement fondamental en termes d'émergence de rançongiciels. Il a paralysé les entreprises d'une manière que la cybercriminalité n'avait jamais fait auparavant.

Mais ce n'est pas comme si vous alliez acheter un produit pour bloquer les ransomwares. Vous revenez en arrière et faites exactement les mêmes choses que vous auriez déjà dû faire pour faire face aux menaces précédentes. Qu'est-ce qu'un ransomware ? Ce sont des logiciels malveillants qui sont placés dans votre environnement.

Eh bien, chaque fois qu'un intrus pénètre dans votre environnement, c'est mauvais. Nous avons donc le droit - si nous continuons à nous concentrer sur le périmètre et à ne pas laisser nos employés ou notre code compromis, alors nous n'avons pas à faire face aux ransomwares.

Ainsi, au lieu de rester assis et de vous inquiéter du prochain rançongiciel à venir, continuez à vous concentrer sur les bases. Et laissez le reste d'entre nous dans le monde de la sécurité spéculer sur l'avenir.

ERIC JONES : Joe et Brent, merci beaucoup pour votre point de vue, votre temps et vos conseils aujourd'hui. Tant de choses à penser pour bien comprendre les fondamentaux, l'importance de la transparence, ce qu'il faut rechercher du point de vue d'une assurance.

Et puis peut-être que la chose la plus importante de toutes est que la sécurité ne devrait jamais être une réflexion après coup. Vous devez l'intégrer dès le début. J'encourage tout le monde, si vous souhaitez en savoir plus sur les offres de sécurité WP Engine ou Cloudflare, veuillez consulter nos sites Web. Et, bien sûr, chez WP Engine, nous avons une mine d'informations sur la sécurité accessible à tous sur notre centre de ressources si vous êtes intéressé par une perspective WordPress spécifique. Donc, encore une fois, à tous ceux qui ont écouté aujourd'hui, merci d'avoir consacré votre temps et d'être parmi nous aujourd'hui.