Introduction à ThreatTank – épisode 2 : tendances trimestrielles des attaques
Tom Gorup : Bienvenue sur ThreatTank, un podcast couvrant les dernières informations sur les menaces. Réponse aux menaces et informations sur le paysage de la sécurité dans le monde entier. Je suis votre hôte, Tom Gorup, vice-président des services de sécurité chez Edgio, et je suis accompagné aujourd’hui de Richard Yew, directeur principal de la gestion des produits chez Edgio Security solutions, et Michael Grimshaw, directeur de l’ingénierie des plates-formes chez Edgio.
Tom Gorup : Bienvenue, Richard, Michael.
Richard Yew : Merci de m’avoir de nouveau ici.
Tom Gorup : cela pourrait devenir un thème récurrent, Richard. Donc, la dernière fois que j’ai ouvert avec une question brise-glace et j’ai senti que nous devions continuer, mais en trouver un n’est pas facile, non ?
Parce que je pense que nous avons fixé une barre solide la dernière fois. Voici mon brise-glace. Et pour ce que ça vaut, je n’ai pas donné le temps d’y réfléchir non plus. Donc, je me joindrai à celui-ci. Mais voici une question. Je vais te le demander d’abord Michael. Je vais vous mettre sur place. Si vous deviez être piégé dans une émission de télévision pendant un mois, un mois complet, quelle émission choisiriez-vous et pourquoi ?
Michael Grimshaw : Je dois admettre que la première chose qui me vient à l’esprit et que je n’étais même pas en vie dans la première série serait probablement Gilligan’s Island parce que l’idée de passer un mois entier sur une île tropicale, même si vous devez utiliser le professeur pour trouver comment obtenir de l’eau courante ou autre chose comme ça. Une belle île tropicale pendant un mois ne semble pas trop mal.
Tom Gorup : quelle réponse. J’adore ça. Non, je n’ai pas vu Gilligan’s Island depuis longtemps, et je ne vais même pas le dire à haute voix ça fait longtemps que je n’ai pas regardé. C’est une bonne réponse. Et vous ?
Richard Yew : Oh, wow, c’est difficile. Vous savez, j’ai réfléchi bien, je veux dire que j’ai dit un Peppa Pig comme s’il y avait une autre émission de télévision qui a des cochons, vous savez que je vais garder le même thème de cochon en cours, mais je suppose que je vais arrêter avec ça.
Je suppose que pour moi, comme Hands Down Game of Thrones, je serais piégé à l’intérieur de Game of Thrones, mais peut-être que j’aurai le premier ou le dernier jour, qui sait ? Mais, oui, je veux dire, allons-y avec ça.
Tom Gorup : C’est ça. Oui. C’est courageux.
Richard Yew : Oui. C’est très courageux. Oui. Je suis assez audacieux mec.
Richard Yew : je vais probablement juste mettre ma cape noire et juste me tenir debout sur un mur et voir ce qui se passe.
Michael Grimshaw : Eh bien, Tom, laissez-moi aussi vous donner l’inverse. N’importe quel Game of Thrones et n’importe quelle série de films sur le thème des zombies serait sur mon ne pas faire partie d’une liste.
Tom Gorup : C’est une bonne réponse. Tu veux survivre, n’est-ce pas ? C’est juste.
Richard, mec, audacieux. Game of Thrones. Donc, j’étais malade la semaine dernière, malheureusement. J’avais Covid, ce qui était misérable. Mais j’ai rattrapé quelques vieux rediffusions de House. Donc je pense que je choisirais House. Je veux vraiment m’asseoir sur un diagnostic et probablement dire que ce n’est pas du lupus. Je dois juste le dire au moins une fois.
Ce n’est pas du lupus. Ce n’est jamais du lupus. Ce serait mon spectacle pendant un mois. Je pense que ce serait un bon moment, au moins je sais que mon taux de survie serait assez élevé par rapport au choix de Richard là-bas.
Tom Gorup : très bien. Nous ne sommes donc pas ici pour parler de séries TV.
Nous sommes ici pour parler d’un nouveau rapport de tendance avec lequel Edgio sort, et dont je suis super excité. Je prends un instantané du 4e trimestre et j’examine toutes sortes de tendances. C’est la première fois depuis très longtemps, depuis des années, je dirais que c’est une sorte de renaissance de ce rapport.
Et nous couvrons toutes sortes de points de données à partir de méthodes de requête, tendances dans le temps, euh, types MIME, toutes sortes de géolocalisation, euh, et bien, je vous ai en quelque sorte amenés ici aujourd’hui pour en parler parce que je pense qu’il y a beaucoup d’idées intéressantes en regardant les données de cette façon, je pense que parfois vous pouvez regarder des ensembles de données.
Tu es genre, eh bien, et alors ? Qu’est-ce que c’est important ? Pourquoi ? Pourquoi est-ce que je regarde ça ? Comment pouvons-nous examiner cette information et en extrapoler une certaine valeur? Et puis je suis tellement excité d’avoir vos deux boulots. Aperçus. Donc, pour les catégories de haut niveau de sujets qui vous sont venus à l’esprit et qui seraient à nouveau intéressés par votre point de vue sur l’un d’entre eux était l’architecture des applications, n’est-ce pas ?
Architecture des applications – ce que vous observez compte
Tom Gorup : si nous examinons ces éléments, ce rapport, en pensant à notre, notre architecture, nos applications, comment nous exploitons nos outils pour être correctement configurés en fonction de l’architecture de notre application et peut-être aussi une certaine conformité. Aspects de, euh, comment pouvons-nous utiliser cette information pour commencer à réfléchir à nos applications d’une manière différente.
Pour commencer, je pense à l’architecture applicative. Donc, j’obtiens un cadre de référence ici. Il y a deux points de données dans ce rapport. Regardez les méthodes de demande dans Mind types, et il y a plus. Nous pouvons certainement nous sentir libres de, vous savez, vous avez vu les rapports avoir accès. Tu peux tirer tout ce que tu as là-dedans.
Mais d’abord, quoi ? Pourquoi est-il important de regarder? Ce genre de choses comme les méthodes de requête dans les types d’esprit. Je veux dire, quand j’ai regardé le rapport pour la première fois, c’était comme neuf demandes de plus de 98% pour obtenir des publications. Quoi ? Bienvenue sur Internet, n’est-ce pas ? Par exemple, pourquoi est-il important d’examiner ces données de cette façon ? Qu’en pensez-vous ?
Michael Grimshaw : non, je dirais que, vous savez, certaines des grandes choses qui me viennent à l’esprit, c’est ce que vous observez importe, ce que vous regardez importe. Donc là, nous pouvons parler d’architecture et de construction comme de nouvelles applications Greenfield et toute l’architecture à ce sujet d’un côté.
Mais la première chose que j’obtiendrais, c’est la puissance de rapports comme celui-ci et de données et d’informations comme celui-ci, évidemment la veille stratégique. Je crois fermement que votre architecture est axée sur votre conformité, vos besoins de sécurité, et en réalité, les exigences non fonctionnelles sont, vous savez, la logique métier de votre application n’est pas un petit pool, mais il est révolu l’époque où vous pouvez vous concentrer uniquement sur la logique métier et une chose, vous devez regarder plusieurs dimensions, comme comment vous pouvez ajuster votre observabilité, comment vous pouvez adopter des approches d’infrastructure et de plate-forme plus avancées comme le repavage et la rotation des références.
Je peux parler, on peut en parler pendant des jours, mais la grande chose à laquelle ça se résume est d’avoir des renseignements exploitables pour savoir ce que vous cherchez. D’après une application, d’après vous avez mentionné des outils, c’est l’une des premières choses que j’appellerais, comprendre où vous étiez, vous savez, quels sont les vecteurs. Ce que les acteurs étatiques tirent parti de ce que les enfants de script et tout le monde entre les deux tirent parti de ce que vous regardez ce que vous savez, que vous fassiez, trimestriellement, vous connaissez les scans, en espérant que vous fassiez des scans plus que trimestriellement évidemment. En fonction de votre profil de conformité, vous devez les effectuer au moins tous les trimestres, mais nous espérons que vous adopterez un modèle DevSecOps adapté à vos besoins, où vous analysez en continu ou où vous surveillez en permanence la sécurité de la construction et de la mobilité.
Donc la première chose que j’appellerais ce sont ces données. Il est important de connaître cette information. Qu’est-ce que vous devez surveiller de plus près, ce que vous devez peaufiner votre pile d’observabilité pour rechercher votre pile d’observabilité de sécurité, et inversement lors de votre quart de travail, n’est-ce pas ? C’est prêter attention à plus de choses et à plus de vulnérabilités potentielles que vous pourriez introduire dans votre code pour vous assurer que vous ne le faites pas.
Tu dois avoir un œil sur ton horizon. Chaque fois que nous aurons une de ces conversations, vous entendrez beaucoup d’analogies, mais c’est un peu comme si vous courez si vous êtes dans un marathon ou si vous faites du cross-country ou quelque chose comme ça, vous gardez les yeux sur l’horizon pour qu’après vous deviez changer tactiquement. D’une façon ou d’une autre à cause d’un nid de poule, vous connaissez une rivière ou quelque chose comme ça. Vous ne perdez pas de vue les horizons vers lesquels vous courez.
Richard Yew : je veux dire, dans l’autre sens, comme si vous regardiez ça, n’est-ce pas ?
C’est aussi quand il s’agit d’architectures applicatives, quand je regarde les données, comme Tom l’a dit, la plupart des requêtes peuvent être imposées, mais vous savez, c’est Internet, n’est-ce pas ? Mais je pense que l’une des choses que vous décomposez, c’est aussi quand vous regardez les données, comme le nombre de demandes, parce que cela vous raconte des histoires comme, quelles sont les conversations sur le contenu que nous obtenons, n’est-ce pas ?
Évidemment. Si vous exécutez beaucoup d’espace d’application, vous savez, surtout comme, disons que vous avez un spa, n’est-ce pas? Comme vos architectures principales, n’est-ce pas ? Vous allez voir beaucoup de publications. Vous allez voir beaucoup de méthodes différentes, n’est-ce pas ? Si vous prenez beaucoup de contenu généré par les utilisateurs, vous pourriez voir beaucoup de messages et mettre, n’est-ce pas? Donc, c’est une très bonne ventilation à voir. Et aussi, étant donné qu’il s’agit de données de sécurité, cela signifie que ces données proviennent d’un pare-feu d’application Web, n’est-ce pas ? Il voit vraiment combien de charges utiles que nous inspectons qui déclenchent beaucoup.
Donc, dans ce cas, souvent, j’ai raison. Mais vous voyez aussi une quantité assez importante de ces choses qui viennent du post parce que c’est là que les charges utiles, donc c’est très, et ça raconte vraiment une histoire sur la surface. La surface de votre attaque, et elle vous dit que si vous regardez juste vos distributions de méthode de requête, n’importe quoi qui reçoit n’importe quel point de terminaison par opposition, n’est-ce pas, vous allez avoir une surface beaucoup plus grande parce que, vous savez, post c’est comme, J’utilise une analogie et les gens me disent que c’est stupide, c’est dans la maison, comme la demande de poste, c’est comme vos ordures et vos toilettes et, vous savez, votre, votre public, euh, quelqu’un, comme vous envoyer une charge utile, vous savez ce que je dis ?
Types MIME
Tom Gorup : J’adore ce que vous dites, cependant, c’est que des choses comme la méthode de demande commencent à peindre un tableau. Racontez une histoire sur votre application, comment elle est utilisée, comment elle est attaquée, où elle peut être vulnérable. Cela vous donne une bonne perspective. Et cela mène directement au type MIME aussi bien.
Une chose que j’ai trouvée intéressante, j’aimerais connaître l’opinion de vos gars à ce sujet, c’est que ce que nous avons vu tourner est une grande quantité, 76% de ces blocs. Encore une fois, cette activité WAF est de type MIME JSON de l’application WAS. Donc beaucoup de prévention autour. Type de requête JSON, et qu’est-ce que cela nous dit sur Internet dans son ensemble, comment les applications sont développées et architecturées ?
Richard Yew : je veux dire, je vais commencer par ça. Comme ça vous dit d’où viennent vos jonques, non ? Dans un sens, JSON a du sens parce que, comme, la plupart des points de terminaison API, euh. Euh, comme reposante, même pas reposante, comme GraphQL, vous l’appelez, non ? Contient des données utiles JSON similaires. UM, c’est ça. Donc c’est par rapport au cours, à mon avis, ça ne devrait pas être quelque chose de surprenant pour beaucoup d’organisations, non ?
Évidemment, vous voyez aussi comme des charges utiles venant de type de contenu HTML, euh, vous voyez un tas comme de XML, non ? Donc, vous voulez vraiment une chose quand il s’agit de concevoir et de mécanismes de sécurité, non ? Vous ne voulez pas seulement regarder JSON, mais vous voulez juste, parce que j’ai vu certains produits de sécurité, ils ne peuvent analyser que XML.
Qu’ils n’ont pas la capacité d’analyser JSON. C’est comme si vous ne pouvez pas analyser JSON, vous ne pouvez pas regarder les charges utiles. Donc, vous voulez vous assurer que vous avez la capacité de JSON. Vous devez vous assurer que votre analyseur est à la vitesse. Je veux dire, devinez quoi ? Parce que la plupart de ce qui est contourné, à un WAV est d’aimer exploiter l’analyseur.
Donc ils envoient des charges utiles soit via un format d’encodage spécial, soit comme eux, ils l’envoient dans un format comme. Même juste parfois juste changer. C’est un JSON, mais il a changé le format en plusieurs parties, peu importe. Et le web a arrêté de l’analyser parce qu’il regardait juste les en-têtes. OH, ce n’est pas JSON. Donc je ne l’analyserai pas.
Voici comment faire glisser la charge utile. Donc c’est certainement quelque chose que vous voulez être capable de faire, prendre des notes comme, wow, JSON, c’est le plus populaire. Vous voulez également regarder ce qui sont quelques-uns des plus obscurs. Ceux et les éléments là-dessus que je veux souligner, mais je les garderai pour plus tard.
Michael Grimshaw : je pense que Richard a fait un excellent point, c’est qu’il n’y a qu’un X et qu’aucun analyseur ne le couvre pas à l’ère moderne du développement web. Je ne trouve pas surprenant que les charges utiles JSON et JSON de l’application représentent un pourcentage aussi important parce que dans le développement web moderne, JSON est dans le monde, vous savez, et ce n’est même pas seulement le développement web.
Vous regardez, par exemple, quelqu’un devrait Cloud. Euh, que vous parliez de CloudFormation et AWS et d’autres, vous savez, laissez-moi utiliser parce qu’AWS est un gros marché. C’était il n’y a pas si longtemps, quatre ou cinq ans, peut-être un peu plus. Je ne me souviens pas de la date exacte, mais CloudFormation était entièrement XML et a ensuite été déplacé vers JSON-based et cela a totalement pris le relais.
Donc, c’est l’infrastructure de développement web, JSON. Ouais, vous devez être capable d’analyser en JSON aussi bien qu’en XML, mais le point de Richard est encore plus ésotérique et le plus aberrant est que vous devez être capable d’analyser toutes les données.
Richard Yew : Oui. En parlant d’aberrations quand je regarde les données, je regarde toujours les points de données plus petits, comme le 1% ou le 0,5% ou quelque chose qui ressort du rapport, c’est que nous avons 0,14. Donc, 0,14% de la quantité de trace similaire de données. D’autres informations non caractérisées, n’est-ce pas ? Mais ça peut sembler étrange, mais quand on parle de milliards de milliards de points de données par mois, je veux dire, 0,14% du milliard, c’est assez important. Et certains de ces types de contenu se révèlent être comme des images. JavaScript et d’autres, comme vous penseriez historiquement que, oh, ce sont du contenu statique, vous savez, comme ceux-ci sont hautement cachables. Pourquoi mettriez-vous WAV devant vos JPEG ?
Vous savez, comme pourquoi vous avez beaucoup d’images, n’est-ce pas ? Que faites-vous cela ? Eh bien, laissez-moi vous le dire, n’est-ce pas ? Il y a cette chose appelée mouvement latéral en sécurité, non ? C’est comme si ces JPEG. Par exemple, à moins que vous ne les mettiez dans le stockage, comme en périphérie, à droite, le stockage net, et où il n’y a que 100% de service, toutes ces requêtes retournent à vos niveaux Web, vous savez, comme dans vos environnements, si seulement 0,1% de ces requêtes reviennent à vos origines, cela signifie que l’attaquant peut réellement expédier des charges utiles, soit sous forme d’en-têtes, de cookies, de chaînes de requête, d’arguments, et cetera, de la requête à un fichier JPEG et envoyer ces choses à votre backend. Donc si vous utilisez le même backend pour votre, disons, votre, vous savez, votre HTML et votre JPEG, comme JPEG, n’est-ce pas ?
Vous pourriez être sensible aux mouvements latéraux parce qu’ils disent, Hey, vous savez, genre, c’est juste le domaine de l’image. Comme, peut-être que tu n’as pas besoin de protéger ça. Beaucoup de gens sont comme, pourquoi je mettrais un WAF? Gaspiller mon argent, vous savez, comme mettre les protections sur une chose principalement statique. Et encore une fois, c’est quelque chose à remarquer.
Vous voulez toujours trouver des défauts parce qu’en tant que défenseur, en tant que quelqu’un qui est une équipe bleue, d’accord, vous devez avoir raison tout le temps. L’attaquant doit juste avoir raison une fois, non ? Vous savez, qui sait, comme les toutes premières charges utiles dans la toute première requête JSON qui arrive à être redirigé vers les origines créé la porte dérobée. Cela pourrait arriver.
Tom Gorup : Oui. 100% et ce que j’aime un peu où vous allez avec ça, aussi, c’est qu’il parlait d’abord de peindre une image ou de raconter une histoire sur votre application. Obtenir une bonne compréhension de l’architecture de votre application. Et où appliquez-vous vos contrôles ?
Parce que jusqu’à votre point où vous pensez être peut-être le moins vulnérable pourrait être cette avenue d’approche quand nous regardons, euh, et encore, c’est dans le rapport aussi bien. Mais lorsque nous examinons les catégories d’attaques atténuées, 45 % étaient en fait des règles de contrôle d’accès, ce qui signifie la prévention des requêtes post.
Si votre application n’accepte pas les publications, comme limiter votre paysage de menaces, limitez les endroits où les attaquants peuvent frapper et pousser votre application en appliquant des règles de contrôle d’accès. Si vous n’acceptez pas la candidature, Jason, bloquez-la. Exact. Empêchez-le. Il n’y a aucune raison de permettre que cela se produise en 1ère place.
Et puis vous apportez un bon point comme, en regardant le genre d’aberrations, les petites parties de l’application. J’adore ce processus de pensée là-bas. Donc, le long de ces lignes, continuons à tirer un peu sur ce fil. Donc, 45% sont des règles de contrôle d’accès où nous avons bloqué 37%. Euh, nous sommes gérés des jeux de règles.
C’est donc toute votre intelligence des menaces et votre script inter-site qui scripte ce genre de taxe. Et puis 19% étaient des règles personnalisées voyant cela et pensant comme la défense de couche. C’est un peu ce que je pensais ici, c’est que lorsque les demandes arrivent, elles passent par ces filtres que vous devez envisager, non ?
Une approche de défense par couches
Tom Gorup : lorsque vous déployez un WAF ou des contrôles de sécurité dans votre application, vous devez comprendre son architecture et ajuster vos outils de sécurité en conséquence. Pour, encore une fois, limiter votre paysage de menaces, mais alors vous avez également besoin de couches, non ?
Michael Grimshaw : vous avez besoin de couches. Et une des choses que je veux, et je veux parler à des couches, mais je pense que c’est ce dont nous parlons ici qui met vraiment en lumière l’importance de la boucle de rétroaction entre votre développement, vos développeurs de fonctionnalités, votre SDLC, vos architectes, et votre équipe de sécurité, parce que si votre équipe de sécurité ou votre WAF ou votre SOC ou quoi que ce soit volent à l’aveugle, vous savez, ils ne savent pas, OK, devrions-nous accepter les charges utiles JSON ici ?
Ne publions-nous pas? Que faisons-nous ? C’est ça, cette communication, cette boucle de rétroaction ? Vous pouvez économiser de l’argent dans la mesure où les ETP perdent du temps, économiser de l’argent sur l’outillage, juste une boucle de rétroaction étroite entre vos développeurs, vos architectes et votre, et votre équipe de sécurité fait toute la différence dans le monde.
Richard Yew : quand il s’agit des couches, je dis toujours, non, je vais mettre en avant le méta-mot à la mode, vous savez, comme la défense en profondeur. Tu sais, genre, je pense vraiment que nous avons besoin, nous devons avoir une mentalité qui, ça a vraiment de l’ordre pour tes conditions. Mais peut-être ai-je tort.
Peut-être qu’il y a un filtre à eau monocouche, vous savez, ils utilisent des charbons comme du charbon de noix de coco, peu importe ce que vous appelez. Exact. Mais habituellement, en général, quand on regarde les titres, n’est-ce pas ? Aucune couche ne peut être supposée être une balle magique. Comme, par exemple, juste parce que vous avez la gestion des bots ne signifie pas que vous voulez vous attendre à ce que la gestion des bots attrape tout, des applications, vous savez, comme les DDoS aux prises de contrôle de comptes.
Chaque mécanisme fonctionne ensemble. Et la façon dont vous essayez de le dire, comme vous le savez, comme. D’accord. Aussi efficace que possible. Comme, donc nous prenons comme 45% de règles d’excès. J’aime l’appeler ACL. Je veux dire, c’est juste, c’est ACL, non ? C’est que l’ACL fonctionne généralement sur notre première couche. Et il y a une raison derrière cela parce que c’est bon marché à faire fonctionner.
C’est juste un tas d’adresses IP, de pays, peu importe. Euh, ASN, signatures JA3, c’est ça ? Tu les laisses derrière parce que c’est une signature statique que tout ce qui viole ceux-ci. On obtient immédiatement l’avenir comme si on était en seconde sous-millisecondes, tu sais, n’est-ce pas ? C’est nos couches entières, le pluriel court en sous-millisecondes.
Mais vous savez, comme si vous vouliez pouvoir vous débarrasser autant de ses déchets, non ? Et j’avais l’habitude d’avoir un copain qui travaillait dans l’industrie, c’est comme il me le disait, c’est ce que nous appelons un rétrécissement de la botte de foin. Tu veux que tu acceptes tout un tas de demandes similaires qui arrivent, non ? Et vous essayez de trouver l’attaque.
C’est un peu comme, eh bien, vous essayez de trouver cette requête HTTP unique qui transporte cette mauvaise charge utile et qui entraîne une violation. Donc vous cherchez un besoin de botte de foin. Donc, soyez en mesure de rapidement enchaîner la botte de foin, retirez autant de ces déchets que possible des couches avant afin que les couches les plus sophistiquées puissent être traitées.
Avec des données supplémentaires, ce qui serait très utile encore, cela revient au fait que nous ne faisons pas que gérer la défense périmétrique, non ? C’est juste parce que vous traversez, vous brisez le mur. Ça ne veut pas dire qu’il y en a, tu devrais avoir des tours de guet, non ? En fait, tout le concept de défense en profondeur est une stratégie militaire qui est venue des Romains alors qu’ils élargissaient leurs territoires au point qu’il est devenu un empire.
Il n’est pas possible d’être juste des murs autour et de s’assurer que vous ne comptez que sur les autres périmètres pour vaincre l’attaque. C’est pourquoi. Nous avons une défense en couches.
Michael Grimshaw : absolument. Et je pense que nous aurions pu le mentionner, nous l’avons couvert dans une discussion précédente, Richard. J’aime l’exemple immunologique ici, c’est que si votre santé dépend d’un environnement stérile, vous êtes un homme mort.
Vous savez, il ne s’agit pas d’éviter, il ne s’agit pas d’avoir un environnement clos et tout dans son stérile. Il s’agit de construire l’immunité. Et la seule façon d’obtenir que c’est comme ça que vous êtes exempt d’agents pathogènes est de développer une immunité contre eux et une approche défensive en couches est nécessaire pour cela.
C’est comme toi. Oui, vous avez besoin des meilleurs pare-feu réseau. Vous savez, vous avez besoin d’un périmètre solide. Mais devinez quoi ? Ça va être violé. Je veux dire, dans le monde des acteurs étatiques et où le monde entier est, est potentiellement une menace. Effectivement, vous devez juste planifier que votre périmètre va être violé.
Alors, une fois qu’ils font ça, quelle est la couche suivante ? Et le calque suivant, et le calque suivant. Et puis comment surveillez-vous cela et dactylographiez ces types de violations pour savoir ce qu’elles recherchent. Oui, c’est impératif
Architecture distribuée
Tom Gorup : C’est intéressant, et pour une raison quelconque, on pense à comment une architecture distribuée joue-t-elle un rôle dans cela ? Parce que je peux voir deux extrémités du spectre ici. Vous pourriez regarder et regarder le risque, vous ajoutez l’étalement, mais alors vous pourriez aussi. Euh, regarde ça et, euh, apporte plus de valeur. Répartition des charges de travail entre, euh, différentes régions ou différents emplacements, permettant une disponibilité accrue.
Alors, où voyez-vous ça jouer ?
Michael Grimshaw : absolument. Nous vivons dans le monde de l’architecture distribuée. Quand vous avez une empreinte mondiale, eh bien. Vous savez, plus de 300 POPS points de présence dans le monde entier. Nous sommes dans une ère de calcul parallèle massivement distribué, et ce n’est pas seulement nous. Je veux dire, euh, ça remonte à plus de 20 ans, mais c’est l’essence du développement web. Infrastructure Web. Vous devez supposer que vous êtes distribué. Que vous courez massivement en parallèle et où, la chose qui déplace l’aiguille ici d’une sécurité, d’un support, et d’une position de coût est la première chose que j’appellerais à éviter les flocons de neige est, et cela concerne aussi la conformité, ce que nous allons aborder ici dans un instant, c’est que si vous exécutez massivement parallèle, massivement distribué, vous avez besoin que votre infrastructure soit aussi similaire que possible avec autant de variations dans cette architecture distribuée et distribuée. Euh, euh, un, parce que quand vous parlez à vos auditeurs, vous pouvez affirmer, vous pouvez attester.
Michael Grimshaw : Oui, nous devons vraiment examiner l’un de ceux-ci parce que c’est un emporte-pièce dans chaque, vous savez, nous devons regarder, vous savez, et vos auditeurs vont l’échantillonner. Ils ne vont pas seulement prendre un exemple et courir avec ça. Vous pouvez jeter un coup d’œil à l’un de nos points de présence mondiaux et ils sont fondamentalement exactement le même emporte-pièce l’un après l’autre qui aide à la sécurité.
Vous avez donc essentiellement le même modèle que vous, lorsque vous travaillez sur vos calques et déployez vos calques un, mais aussi lorsque vous suivez, scannez et observez. C’est l’une des grandes choses dont je parlerais en ce qui concerne l’architecture distribuée et la raison pour laquelle je mentionnais qu’avec la conformité, c’est parce que si vous êtes dans un système massivement distribué, vos auditeurs ne voudront pas tester et auditer chacun d’eux s’ils peuvent valider et vérifier et vous pouvez affirmer qu’ils sont corrects. Exactement la même architecture, ils sont concurrents les uns des autres.
Tom Gorup : ça doit être plus facile à dire qu’à faire, n’est-ce pas ? Surtout en parlant d’une architecture distribuée dans notre scénario, n’est-ce pas ? Nous ne parlons pas du déploiement d’un tas d’instances EC2 qui proviennent d’une, vous savez, image dorée assis quelque part.
On parle de matériel. Exact. Dans un sens. Et comment opérationnaliser quelque chose comme ça ?
Michael Grimshaw : C’est un excellent point. Et là où cela vient à un là, c’est une approche multi-couches pour cela aussi. Pas seulement la sécurité dans ce domaine vient de vous, de votre approvisionnement et de votre équipe de gestion du cycle de vie, vous devez être aligné sur cela parce qu’un bon exemple, la raison pour laquelle laissez-moi obtenir Kubernetes est un excellent exemple.
Il est distribué en parallèle, pas à l’échelle mondiale, mais vous n’allez pas exécuter un cluster Kubernetes partout dans le monde. Mais Kubernetes obtient un bon exemple de cela est que vous rencontrez des problèmes dans Kubernetes. Si vous avez tout un tas de serveurs qui ont des pilotes différents ou différents, vous savez, des cartes de pseudonyme ou du matériel différent, vous ne pouvez pas exécuter Kubernetes.
C’est pourquoi, comme je l’ai dit, nous travaillons avec votre équipe de gestion du cycle de vie et votre équipe d’approvisionnement pour banaliser votre infrastructure. C’est la pointe de la lance sur la pointe de la lance sur ça. Vous voulez que votre matériel soit aussi similaire que possible les uns aux autres. Maintenant, laissez-moi vous dire qu’un grand risque que nous avons récemment connu pendant le Covid est le problème que nous avons trouvé avec la logistique et le choc massif sur l’espace de distribution mondial a atteint où vous, même si vous utilisiez du matériel banalisé de coupe-biscuits avant COVID avec les retards dans l’expédition avec les chocs à l’expédition, au transport et à la logistique.
Michael Grimshaw : de pouvoir même obtenir le même type de chipsets ou autre chose comme ça et ce n’est pas seulement vous, c’est les gens que vous achetez du matériel chez leurs fournisseurs, etc C’est un peu une grosse boule de virage, ce qui fait apparaître la deuxième couche où vous devez vous adapter et qui est activée lorsque vous arrivez à l’imagerie et aux logiciels que vous utilisez, tout d’abord, comme votre hyperviseur, votre système d’exploitation ou votre hyperviseur ?
C’est la couche suivante où, même si elle n’est pas complètement uniforme en dessous, cependant, vous voulez y arriver aussi près que possible. La couche suivante est de le rendre autant coupeur de cookie et uniforme dans votre imagerie et dans votre couche d’hyperviseur OS. Et puis, à partir de là, une approche similaire avec les applications.
Vous voulez que cela soit aussi standardisé que possible pour la sécurité des coûts pour tout un tas de raisons.
Richard Yew : vous savez, je vais vous dire comme quand il s’agit d’applications. Oui, vous savez, contesté, je sais que c’est probablement contraire à la croyance populaire, et cela pourrait être un peu contre-intuitif parce que nous pensons à une architecture bien distribuée.
Nous prenons donc des serveurs logiciels centralisés, des environnements cloud, et nous sommes distribués dans le monde entier. Et si je vous disais qu’avoir une architecture distribuée réduit votre surface d’attaque ? Ça a l’air bizarre. Ça a l’air, mais, mais pensez-y de cette façon, non ?
En ayant distribué, et c’est pourquoi je pense que c’est très important quand vous concevez des applications, surtout nous parlons de site web, non ? Vous ne le faites pas, la conception et ce que je trouve une erreur commune, et c’est la sécurité limite. Donc, si je détourne un peu le sujet, c’est que je trouve qu’il y a une erreur quand j’ai vu des gens, des clients, des organisations, ils vont concevoir les applications basées sur une architecture centralisée et essayer de les exécuter sur la plate-forme distribuée comme un CDN, ensuite, vous devez créer beaucoup d’optimisation et pourtant, comme, Oh, qu’est-ce qui doit être expédié, vous savez, après le fait à la logique, mais vous savez, le moderne, c’est ce qu’on appelle un design moderne, non ?
Il s’agit de concevoir des applications avec des architectures distribuées à l’esprit. Ce serait comme, par exemple, vous êtes habitué à traiter beaucoup de logiques dans un emplacement centralisé. Il vous suffit d’utiliser CDN pour mettre en cache votre JPEG et vos fichiers statiques, etc Mais que diriez-vous d’expédier certaines des logiques?
Disons que vous prenez un exemple très simple, comme vos redirections, n’est-ce pas ? Comme votre infrastructure centralisée d’origine, vous allez effectuer des redirections pour un client. Et si vous avez des dizaines de milliers de redirections liées ? Exact. Euh, et si tu décalais ces logiques vers le bord ?
Et si vous déplaciez ces choses ? Et en faisant ça, quand je parle de surface d’attaque, c’est vrai, en déplaçant cette logique vers le bord, c’est vrai, vous réduisez les charges, vous réduisez la probabilité d’échec dans un système centralisé, comme les architectures, en ayant déchargé une partie de cela, vous savez, la sécurité extérieure est ce que CIA, non ?
Richard Yew : nous parlons de la disponibilité. C’est très important. Donc, je dirais en déplaçant beaucoup de ceux-ci, y compris les mécanismes de sécurité. Donc, si vous êtes capable de filtrer à nouveau, de réduire la botte de foin de l’attaque au bord extérieur des périmètres, d’accord, vous êtes sensible, moins vulnérable dans votre centralisé, vous savez, un cloud ou un matériel similaire, espérons que plus.
Richard Yew : vous les gars 2024, vous savez, mais du matériel, mais en gros nous appelons l’infrastructure Origins et c’est très important. Je peux juste dire qu’il y a tellement plus de choses que vous pouvez faire parce que nous sommes évidemment à la limite de ce que nous mettons en œuvre beaucoup de technologies et je vais vous dire, mec, comme faire du comptage distribué.
En 1 milliseconde et en ayant tous les serveurs, comme les choses à travers, d’accord, que les données, c’est pénible, vous savez, quand vous essayez de synchroniser le nombre de requêtes par seconde sur l’ensemble de vos infrastructures, euh, au sein d’un pop, non ? UM, mais je, je pense que c’est quelque chose que tu veux utiliser.
Richard Yew : donc, donc, au lieu d’avoir juste un cerveau central, comme, euh, des logiques dans votre, dans votre architecture centralisée. Commencé peut-être à diviser tout comme les humains, vous savez, les cerveaux humains sont des architectures techniquement distribuées. Vous avez votre cerveau et votre cerveau de lézard. Et devinez quoi ? Parce que quand vous touchez quelque chose de chaud, vous n’aurez pas le temps de réagir.
Richard Yew : si ces choses doivent passer par un cerveau central. Tu dois te brûler avant de te retirer, n’est-ce pas ? C’est pourquoi si vous voulez, commencez à penser à ce qu’est une nouvelle conception d’architecture. Peut-être qu’au lieu de faire de l’apprentissage automatique et de la formation et tout dans le centralisé, vous faites de l’inférence sur la périphérie, puis vous faites une formation dans des endroits centralisés.
Encore une fois, il revient à aimer. Dans un sens, vous réduisez un peu la vulnérabilité et rendez l’ensemble de votre système plus robuste du point de vue de la sécurité.
Michael Grimshaw : Oui. Ouais, et ce truc dit parfaitement ce que nous parlions juste de superposition, c’est parce qu’en s’éloignant d’une approche centralisée, euh, euh, ou ce dont nous parlions avec l’immunologie aussi, en s’éloignant d’une approche centralisée, euh, euh,
Vous, si, quand vous êtes attaqué et que vous êtes mis en gage, euh, la quantité de données ou, ou, ou, l’exposition que vous avez est extrêmement limitée, donc ce n’est pas un booléen complet, euh, suis-je protégé ou ne suis-je pas? Quand tout est centralisé. D’accord. S’ils sont là et qu’ils ont accès aux données, ils auront accès aux données, les distribueront.
D’accord. Peut-être, peut-être une région ou un sous-ensemble ou un sous-système. UM, UM, un attaquant peut tirer parti d’un jour zéro ou quoi que ce soit et entrer, mais ils n’ont pas tout votre système. Et c’est aussi une chose de résilience parce que vous ne perdez pas tout votre cortex cérébral d’un seul coup.
Richard Yew : au fait, Lindsay bot vient de me vérifier les faits et, euh, je suppose que j’ai utilisé une mauvaise analogie. Euh, l’humain est, je suppose, je suppose que nous, nous n’avons pas de cerveaux et ailleurs, mais j’aurais dû, j’aurais dû dire que c’est une pieuvre. Une pieuvre a comme des cerveaux et tous les bras. Oui. C’est une véritable architecture distribuée.
Géolocalisation – où bloquons-nous le plus d’attaques ?
Tom Gorup : Oui, c’est juste. C’est bien. Donc, en restant dans les lignes de l’architecture distribuée, peut-être en tirant un peu dans la conformité ici. Une des statistiques que je pensais être. C’était assez intéressant pour moi, du moins pour voir sur papier, je regardais la géolocalisation. Alors, où bloquons-nous les attaques des cinq premiers pays ?
D’accord. J’ai ce top cinq pays étaient nous, la France, l’Allemagne, la Russie et la Tchétchénie. Ce que j’ai trouvé super intéressant ici, c’est pour ce qui vaut la peine de savoir qu’il y a beaucoup d’APT qui s’échappent de Chine. Ils ne sont pas sur la liste. Pas sur la liste, ce que je trouvais intéressant quand on pense à la géolocalisation.
Je pense que beaucoup de gens se tournent vers le geofencing. Hey, laissez-moi enfermer dans des pays dont je sais qu’ils sont susceptibles d’être attaqués, mais à 26%. Le détestateur numéro un venait des États-Unis. Qu’est-ce que ça vous dit les gars ? Je pense également que je pense y penser du point de vue de la conformité. Comment se fait qu’est-ce que le geofencing comme dans, vous savez, 2023, 2024, c’est où nous en sommes maintenant.
Richard Yew : Je veux dire, mon opinion, d’accord, je sais que nous avons, comme, chaque client, vous savez, quand nous arrivons à bord, nous parlons de contrôle des exportations, et nous devons, comme, faire, genre, ces contrôles avec, comme, le geofencing, je me sens comme certaines de ces choses, certaines de ces exigences à être revisitées car je sais que ce n’est peut-être pas quelque chose que tout le monde veut entendre, surtout si vous dirigez GRC, je m’excuse à l’avance si je vous donne mal à la tête, mais je pense que nous sommes à une époque où c’est comme si tout le monde mettait la main sur VPN et tout, non ? Et si facile de faire tourner la VM partout. Je me souviens quand on regardait Black Hat l’année dernière, on regardait des distributions de Like The ISP pour une attaque anonyme DDoS au Soudan, non ?
Richard Yew : ils utilisent un hébergeur. Partout. Nous savons d’où ils viennent, comme ils viennent de ce pays spécifique, l’Europe de l’est, vous savez, comme c’est là que l’organisation est, n’est-ce pas ? Mais, alors l’attaque vient de n’importe où, comme de nos jours. Donc c’est comme si tu bloquais un hacker chinois par Joe Fencing China ? Est-ce que ça marche même de nos jours ? N’est-ce pas ?
Michael Grimshaw : non, mais vous avez tout à fait raison. Et, la Chine est bien connue historiquement pour utiliser cette approche très, très VPN et, et en obscurcissant vraiment l’origine de l’attaque, euh, évidemment avec la Russie, ils utilisent là-bas, il y a tellement d’un pays, vous savez, presque l’État, encourageant presque des acteurs individuels en Russie à y participer.
La structure de commandement et de contrôle de la Chine est un peu moins orientée, dirons-nous, vers la foule ou, hum, hum, hum, comme la Russie ou, ou, ou le Cheshire et des choses comme ça ont été décentralisées. Exactement. UM, bon appel. Euh, mais oui, et Richard, je pense absolument que tu as raison. Nous devons revoir ce point, mais il y aura des clients et des segments de marché.
Et les marchés verticaux qui ont des exigences réglementaires. Donc, et l’un des gros avec lesquels vous ne vous mêlez pas est le Bureau du contrôle des avoirs étrangers, OFAT. Et c’est là que le geofencing et avec, comme en particulier n’importe lequel des services financiers, l’industrie bancaire, um, s’assurer que, vous savez, assurez-vous que vos services bancaires ou financiers ne sont pas disponibles pour la Corée du Nord, par exemple, ou l’Iran et d’autres endroits sur la liste.
Le geofencing est toujours important, en particulier pour les exigences réglementaires. Nous devons les revoir. Et, et nous avons besoin, euh, en fait, ceci, cela vient d’arriver en Ukraine où, euh, euh, euh, il a été appelé ça, que le Fort russe, tandis que, [00:39:00] Starlink utilise la géolocalisation. Pour l’empêcher d’être utilisé en Russie, les opérations russes les soldats et les opérateurs russes sont, utilisent, euh, provenant d’autres pays dans, euh, le territoire ukrainien occupé.
La liste est longue sur le double usage. Des matériaux à double usage, des choses comme celles-là qui pourraient être utilisées à des fins civiles et militaires et comment elles proviennent souvent de pays tiers, et c’est la même chose ici, mais il existe encore des lignes réglementaires absolument strictes. Certains clients ont beaucoup à traiter avec ou geofencing.
Richard Yew : vous avez raison. C’est juste une course aux armements. Je pense que, pendant que nous parlons d’architecture distribuée, nous avons parlé de l’importance pour nos clients de l’utiliser pour nous protéger. Mais comme Mike et moi l’avons dit, les deux attaquants utilisent des architectures distribuées.
Richard Yew : je veux dire, ils sont, eh bien, je veux dire, c’est plutôt drôle, c’était tout l’intérêt des DDoS. N’est-ce pas ? Je veux dire, c’est de là que vient le D.
Tom Gorup : Oui, c’est bien. Tu sais, je suis déçue que nous manquions de temps parce que je pense que nous pouvons passer au moins 20 minutes de plus sur ce seul sujet.
Réflexions et recommandations finales
Tom Gorup : mais puisque nous sommes en train de courir un certain temps, j’aimerais entendre un peu, vous savez, penser à ce rapport, penser à certains des points de données dont nous avons parlé ici. De l’architecture applicative à la conformité, au geofencing, en passant par l’ensemble du gambit. J’aime entendre vos pensées et vos recommandations à l’auditoire.
Par exemple, que devrions-nous regarder ? Comment peuvent-ils mieux se protéger?
Michael Grimshaw : Oui, j’adore ce reportage. Vous savez, je veux le ramener et parler du rapport. Nous avons parlé de beaucoup de choses, mais l’une des choses qui, et peut-être c’est parce que je traverse. Qu’est-ce qu’un audit PCI en ce moment est l’une des choses que j’aime dans ce rapport est dans deux choses qui me viennent à l’esprit, euh, autour de la façon dont ce rapport et ces approches aident à votre sécurité et surtout vraiment votre stature de conformité est dans PCI. L’une des exigences de PCI est d’établir un processus pour identifier les vulnérabilités sécurisées de sécurité des vulnérabilités en utilisant des sources externes d’information réputées et attribuer un classement des risques. Ce rapport ne donne pas exactement de CVEs, mais cela fait encore partie de votre approche d’audit en couches. Je voudrais, vous savez, j’adore prendre un rapport comme celui-ci avec des détails sur peut-être des vulnérabilités du système d’exploitation ou un décalage à gauche comme la base de données de vulnérabilités en arrière-plan.
Michael Grimshaw : et être capable de dresser un tableau complet pour nos auditeurs d’une part, et puis une autre exigence PCI est de s’assurer que vous êtes et moi sommes juste concentrés sur PCI. ISO Sock à tout un tas d’autres régimes. Mais l’autre chose est qu’il est important que vos employés soient formés et à jour sur le paysage de la sécurité et comment éviter cela.
Et oui, vous faites de la formation sur une base annuelle. Tu sais, tu dois faire de la formation quand quelqu’un est embauché. D’accord. Chaque année après cela, mais des rapports comme celui-ci, c’est absolument quelque chose que je recevrais à travers chacun de mes employés et dans toute l’entreprise juste pour augmenter la sensibilisation à la sécurité, aider à leur conformité, aider à votre sécurité. Je suis un grand fan.
Tom Gorup : C’est un excellent conseil. J’adore ça. Et toi Richard ?
Richard Yew : je dirai certainement comme, vous savez, parfois avoir la visibilité est très important. Et je dirais de rendre les choses plus faciles, non ? Ce serait bien d’avoir ce genre de visibilité sur toutes les applications, du moins sur ce que nous parlons des applications publiques, car nous n’allons pas examiner tous vos points de terminaison sur la gestion, comme vos ordinateurs portables et Mac, mais au moins, nous pouvons voir ce qui entre et sort parce que je suis fermement convaincu qu’il faut avoir un seul panneau de vision pour tout ce qui, comme Internet, entre et sort d’ici.
Comme nous parlons de toutes les requêtes HTTP, chaque requête externe, à l’intérieur et à l’extérieur du réseau, doit être cataloguée et être excellente. Par exemple, s’ils sont tous recueillis et peuvent être déclarés sous une vue consolidée comme ce dont nous avons parlé ici, je pense que cela va également aider à faciliter votre conformité, en particulier lorsqu’il s’agit de fournir des preuves, etc
So. D’accord. Encore une fois, la visibilité est importante, n’est-ce pas ? Vous savez, si vous regardez les trois, eh bien, en fait cinq phases d’un cadre de sécurité NIST, non ? Je veux dire, qu’il y a ça à l’extrême gauche, il y a juste un texte comme les préventions et puis vous devez répondre, non ? Mais, vous savez, ayant la capacité d’avoir de la visibilité, la détection est très importante.
Vous ne pouvez pas atténuer ce que vous pouvez voir.
Tom Gorup : Oui, oui. J’assimile toujours la posture de sécurité, la visibilité, les expositions et les menaces. Je ne peux pas protéger ce que je ne peux pas voir. J’ai besoin de comprendre où sont mes faiblesses et comment je suis attaqué. Ce sont les trois éléments qui s’associent vraiment pour définir votre posture de sécurité.
Et c’est devenu un peu intéressant aussi de partager ça avec d’autres personnes dans l’entreprise. Une des plongées profondes que nous faisons dans le rapport ainsi que de creuser dans la traversée de répertoires, c’était en fait à peu près le type d’attaque numéro un que nous voyons encore très important sur Internet aujourd’hui.
Maintenant, nous nous protégeons contre elle, mais cela ne signifie pas que les applications ne sont pas vulnérables à elle. Et s’assurer que vos ingénieurs ou développeurs comprennent comment cette attaque peut être utilisée contre vous est un excellent moyen de vous assurer que vous construisez du code sécurisé à partir de zéro. Et ce dont nous avons parlé aujourd’hui, c’est de penser à l’architecture applicative, pas seulement à votre architecture applicative, mais aussi à votre entreprise et à son fonctionnement.
Donc, en utilisant cela pour informer vos outils de sécurité, n’est-ce pas ? Vous avez donc votre architecture applicative de quels types de requêtes dois-je m’attendre à voir ? Quels types de types MIME, mais aussi où mon entreprise est-elle en mesure d’opérer, de les appliquer et de les intégrer dans le cadre des contrôles de vos outils de sécurité ?
Je pense que ce qui m’excite dans le rapport n’est pas seulement d’examiner les données, mais aussi prendre le temps de réfléchir à, comme, comment puis-je utiliser cette information pour penser le monde un peu différemment et peut-être l’utiliser pour informer mes outils de sécurité pour mettre plus de contrôles, de contraintes, empêcher mon entreprise d’être explosée. Vous savez, en fin de compte, c’est ce que nous sommes ici pour faire, c’est protéger l’entreprise, lui donner la liberté de manœuvrer pour gagner de l’argent pour f mandants et apporter de la valeur à nos clients. Tellement bon truc. C’est tout ce que nous avons pour aujourd’hui. Merci à tous de vous être joints à ThreatTank.
Si vous voulez rester à jour avec les dernières informations sur les menaces d’Edgio, passez à edg.io. C’est edg dot io et abonnez-vous, vous savez, vous obtiendrez plus d’Intel au fur et à mesure qu’il sortira. Michael, Richard adorait la conversation. Je me sens comme encore une fois, nous aurions pu aller au moins encore 45 minutes. C’était super.
Tom Gorup : J’apprécie vraiment votre temps.
Richard Yew : Oui. Oui. Merci de nous avoir accueillis ici. Merci pour votre engagement et vos discussions.
Michael Grimshaw : Merci pour la bonne information, Tom. Oui. J’apprécie. Et toujours amusant de bavarder avec toi, Richard. Exceptionnel.
Richard Yew : de même, mec. À plus.
Tom Gorup : jusqu’à la prochaine fois.
