Sur l'amélioration de la sécurité avec Steve Wilson

Steve Wilson est le directeur des produits chez Contrast Security, avec plus de 25 ans d'expérience dans le développement et la commercialisation de produits dans des entreprises technologiques de plusieurs milliards de dollars telles que Citrix, Oracle et Sun Microsystems. Dans cet AMA, Steve nous parle de la sécurité sans serveur, de la sécurité des applications dans l'écosystème JAVA, des SBOM et des meilleures pratiques. Ce fil de discussion de Mónica Freitas, Steve Wilson, Zach Taylor, Victor de Avila, Jack Boreham et Sara Pinto s'est produit sur la chaîne officielle #amas de slogging et a été modifié pour plus de lisibilité. Hey @channel, veuillez vous joindre à moi pour accueillir notre prochain invité AMA, Steve Wilson. Steve est actuellement chef de produit chez Contrast Security. Aujourd'hui, son équipe est responsable de l'ingénierie, de la gestion des produits et de la conception des produits pour tous les produits. Steve a plus de 25 ans d'expérience dans le développement et la commercialisation de produits dans des entreprises technologiques multimilliardaires telles que Citrix, Oracle et Sun Microsystems. Avant Contrast, Steve était vice-président de la gestion des produits pour Citrix Cloud, où il a dirigé la transformation des produits Citrix traditionnels sur site en SaaS.

Chez Oracle, il a dirigé l'ingénierie de base pour une gamme de produits de logiciels de gestion de systèmes d'un milliard de dollars. Pendant son séjour chez Sun Microsystems, Steve a été l'un des premiers membres de l'équipe qui a développé le système de programmation informatique Java, l'ensemble d'outils de développement logiciel le plus utilisé de l'histoire.

N'hésitez pas à poser des questions à Steve sur :

Salut Steve Wilson ! C'est super de vous avoir avec nous ! Pourriez-vous commencer par nous parler un peu de votre parcours et de la façon dont vous êtes arrivé à travailler avec Contrast Security ?

Bonjour Monica Freitas ! C'est cool d'être ici. J'aimerais commencer par remercier HackerNoon de m'avoir fait rejoindre leur AMA et j'ai hâte de répondre à vos questions.

Je suis Chief Product Officer chez Contrast Security, un leader de la sécurité des applications qui permet aux développeurs de sécuriser en même temps qu'ils codent. Notre plate-forme fournit aux développeurs des solutions de sécurité en libre-service pour améliorer l'efficacité tout au long du cycle de vie du développement logiciel tout en protégeant les applications contre les vulnérabilités avant, pendant et après la production. Je tire parti de mes plus de 25 ans d'expérience dans le développement et la commercialisation de produits pour diriger mes équipes responsables de l'ingénierie, de la gestion des produits et de la conception de tous les produits de Contrast.

2 faits amusants sur moi :
- J'ai une ceinture noire au deuxième degré en Taekwondo.
- J'aime jouer des airs de rock classique à la guitare.

N'hésitez pas à me suivre sur Merci, Mónica Freitas, heureuse de parler de la façon dont je suis arrivée à Contrast ! J'ai rejoint il y a environ 18 mois après avoir travaillé dans de grandes entreprises comme Citrix, Oracle et Sun Microsystems. J'ai travaillé dans des rôles de contributeur individuel et de gestion à la fois en ingénierie et en gestion de produits, remontant à l'époque où j'étais l'un des premiers membres de l'équipe Java à la fin des années 90. Heureux de répondre aux questions sur les premières anecdotes sur Java/Sun si les gens sont intéressés. 🙂 Histoire rapide cependant sur la façon dont je suis arrivé à Contrast. Dans mon rôle précédent, je me suis retrouvé dans une situation où une équipe de centaines d'ingénieurs a été complètement déraillée par une équipe de sécurité exécutant un mauvais produit de "numérisation de code". Cela a généré d'énormes quantités de dette technique pour nous (que nous étions tenus de régler), mais n'a entraîné pratiquement aucune amélioration de notre posture de sécurité. Cela a fait déraper les horaires et a créé une énorme frustration. En rejoignant Contrast, j'ai réalisé qu'il y avait une meilleure façon de faire ça ! Salut Steve! Pouvez-vous expliquer ce qu'est le serverless ? Merci, Zach Taylor ! Serverless est l'un de ces termes qui signifie beaucoup de choses pour beaucoup de gens, alors décomposons-le. Il s'agit essentiellement d'un ensemble de technologies conçues pour rendre l'informatique côté serveur plus efficace et plus simple. L'une des utilisations du terme concerne l'idée d'abstraire le concept lourd d'une "machine virtuelle" (ala VMware) et au lieu d'utiliser des constructions plus légères et évolutives comme Docker Containers et Kubernetes. Cependant, je pense qu'il y a un mouvement beaucoup plus intéressant à l'intérieur de Serverless... La plus grande révolution en 20 ans pour l'architecture d'application est les fonctions en tant que service. L'exemple le plus populaire est celui d'Amazon Web Services (AWS) Lambda, bien que d'autres clouds comme Microsoft et Google aient ajouté des constructions similaires. De la même manière que les servlets Java constituaient une amélioration massive de l'architecture Web par rapport au "CGI" qui l'a précédé, les fonctions sans serveur peuvent être 100 fois plus rapides et moins chères que les architectures traditionnelles. Ces fonctions ne sont pas amusantes tout le temps, elles sont plus "basées sur les événements" et ne s'exécutent qu'en cas de besoin. Vous les voyez être utilisés dans des endroits où une évolutivité massive et un faible coût sont essentiels. Applications de l'Internet des objets (IoT) où vous pouvez renvoyer des données de milliers ou de millions d'appareils à un service de collecte de données. C'est vraiment excitant.

C'est très excitant pour les développeurs ! Et lorsque vous mentionnez l'IoT, cela semble ouvrir les portes à de nombreux cas d'utilisation différents.

En quoi la sécurité sans serveur est-elle différente, par exemple, de la sécurité des applications traditionnelles ?

Excellente question, Zach Taylor ! Il y a beaucoup de différences ! Du côté "plus", vous perdez beaucoup de choses dont vous ne pouvez "pas" vous inquiéter. Vous n'avez pas à vous soucier d'avoir un système d'exploitation ou même un AppServer que vous devez corriger. Tout cela "disparaît" sous vous. Certaines versions existent encore quelque part, mais vous ne les voyez ni ne les gérez. C'est un gros plus du point de vue de la sécurité ! Cependant, du côté "attention", votre code pour votre application sera VRAIMENT différent. En fait, vous devez supposer que vos outils de code AppSec (comme votre "scanner de code") ne fonctionnent pas du tout. Tous les points d'entrée et de sortie sont différents, votre flux logique est donc différent. Vous avez besoin d'outils AppSec entièrement nouveaux pour vous assurer que vous êtes en mesure de repérer les vulnérabilités de type OWASP Top 10 (qui existent toujours). En fait, OWASP a toute une qui vaut la peine d'être consultée. Ainsi, vous avez encore deux grandes choses à vous soucier dont vos outils AppSec doivent vous aider : les vulnérabilités dans le code Open Source que vous apportez et les vulnérabilités dans le code personnalisé que vous écrivez. Cependant, il y a aussi un nouvel élément à prendre en compte, à savoir vos autorisations de gestion des identités et des accès (IAM) sur chaque fonction. Il s'agit d'un élément essentiel pour assurer la sécurité de votre code lorsqu'il s'exécute dans le cloud public, mais il est fastidieux de le faire à la main. Mieux vaut vous assurer d'avoir un outil qui peut automatiser cela pour vous. Wow, c'est très perspicace ! Ainsi, malgré les compromis (avantages et inconvénients des deux), dans l'ensemble, il semble que l'automatisation soit un élément clé pour combler les lacunes ? Ce Top 10 de l'OWASP a l'air très intéressant, je vais certainement approfondir cela - merci pour le partage ! Salut Steve! Si une organisation envisage de passer à des environnements sans serveur/cloud natifs, quels sont les menaces/dangers les plus immédiats ? Que doivent garder à l'esprit les équipes de sécurité pour améliorer la protection ?

Hé, Victor de Avila, excellente question ! Alors que la technologie sans serveur élimine de nombreuses responsabilités de sécurité pour les technologies sous-jacentes, les développeurs doivent toujours sécuriser les fonctions sans serveur. Si le code est écrit de manière non sécurisée, l'application peut toujours être vulnérable aux attaques traditionnelles au niveau de l'application, comme le script intersite (XSS), l'injection de commande/SQL, le déni de service (DoS), l'authentification et l'autorisation brisées, les mauvaises configurations de sécurité , et beaucoup plus.

Non seulement les équipes de sécurité doivent gérer les vulnérabilités et expositions courantes (CVE) ou les risques associés aux bibliothèques open source, mais les environnements sans serveur introduisent également des menaces entraînées par un contrôle d'accès rompu, en particulier lorsque les développeurs doivent ajouter des autorisations pour prendre en charge les fonctionnalités nécessaires. Dans cette situation, l'équipe de sécurité demande souvent au développeur de sélectionner dans une liste d'autorisations prédéfinies un accès plus privilégié que nécessaire. Un bon processus d'automatisation pourrait être une excellente opportunité pour une application de moindre privilège, ce qui était impossible à ce niveau auparavant. Cependant, automatiser ce processus à grande échelle, de manière précise et rapide n'est pas facile.

Dans un environnement sans serveur, la surface d'attaque augmente également car les attaques de désérialisation sont plus courantes et l'audit et la surveillance sont plus difficiles que dans les applications traditionnelles. Par conséquent, les organisations doivent suivre les principes du moindre privilège et garantir des contrôles d'accès solides pour réduire la surface d'attaque et garantir que seules les personnes autorisées peuvent y accéder.

De même, les équipes DevSecOps doivent également être conscientes de la « prolifération » dans les fonctions sans serveur. Les fonctions peuvent avoir plusieurs versions, dans différentes régions et sur plusieurs comptes, ce qui rend difficile pour les équipes de gestion et de sécurité de comprendre la taille globale de l'inventaire sans serveur au niveau de l'organisation. Pour résoudre ce problème, ils auront besoin de solides contrôles de gestion des actifs pertinents à la fois pour l'infrastructure cloud et sans serveur.

Enfin, les équipes doivent tenir compte de leurs autorisations de bibliothèque. Bien que cela ne soit pas différent de la sécurité des applications habituelles, les fonctions ont tendance à avoir de nombreuses dépendances. De plus, dans certains cas, même si le code semble propre, l'infrastructure (comme IaC) peut introduire plus de bibliothèques au moment du déploiement, ce qui entraîne des vulnérabilités tierces manquées. Les équipes DevSecOps doivent activer des processus de sécurité solides avec un œil critique sur ces considérations spécifiques au sans serveur. Salut Steve Wilson ! J'aimerais connaître votre temps de travail chez Oracle. Qu'avez-vous fait là-bas ?

Salut, Jack Boreham, merci d'avoir demandé ! J'ai été chez Oracle pendant environ 3,5 ans de 2010 à 2013. Pendant ce temps, j'étais "VP of Core Engineering" pour l'équipe Enterprise Manager. Il s'agissait de la suite d'outils de gestion d'Oracle pour l'ensemble de son portefeuille (du matériel à l'hyperviseur en passant par la base de données, le middleware et les applications). C'est un travail où j'ai beaucoup appris sur le travail à grande échelle (mon équipe comptait environ 500 personnes réparties entre l'Amérique du Nord, l'Europe (France et République tchèque) et l'Inde. Oracle avait une culture d'entreprise étrange, mais une culture d'ingénierie très disciplinée (avoir J'ai commencé avec la base de données Oracle. J'y ai beaucoup appris sur les tests et la qualité de conduite.

Mais, juste pour élaborer, j'ai rejoint Oracle lors de l'acquisition de Sun Microsystems. En fait, j'ai rejoint Sun au milieu des années 90 en tant que codeur travaillant sur le kit de développement Java où j'ai pu travailler avec toutes sortes de personnes intelligentes comme James Gosling (et bien d'autres qui sont devenus des programmeurs célèbres et ont construit des choses géniales). J'ai commencé à travailler sur le Java GUI Toolkit, puis je suis devenu le premier ingénieur de performance à temps plein pour Java. En fait, j'ai écrit un à ce sujet. Je vais fournir un lien juste pour le plaisir, mais il est super obsolète et je ne suggérerais à personne de le lire maintenant ! 😉 Je suis passé à la gestion et j'ai dirigé l'équipe NetBeans IDE (mon travail préféré, BTW) puis les équipes de gestion de la virtualisation et des systèmes de Sun. Faites-moi savoir si vous avez d'autres questions sur n'importe quelle partie de ceci. Beaucoup d'histoires amusantes sur Sun/Oracle.

Steve Wilson c'est un grand voyage !
Quels défis avez-vous rencontrés dans votre rôle au sein de Contrast ? Et qu'entendez-vous par solutions de sécurité en libre-service ? Avez-vous un ensemble établi de solutions de sécurité et n'importe quelle entreprise peut choisir celle qui répond le mieux à ses besoins ? Est-il possible pour les entreprises de demander à Contrast des solutions sur mesure ?

Mónica Freitas, merci d'avoir posé des questions sur Contrast ! Contrast est une entreprise spécialisée dans les outils pour aider les développeurs à créer des applications sécurisées. Beaucoup de gens pensent à des choses comme les outils de sécurité du réseau, de l'identification ou des points finaux lorsqu'ils considèrent la sécurité (et c'est important), mais qu'essayons-nous tous de protéger contre les pirates ? Il s'agit vraiment de nos applications et des données qu'elles stockent pour nous. C'est pourquoi la sécurité des applications est si importante et ce sont les outils construits par Contrast. Nous avons ce qu'on appelle une plate-forme de code sécurisé. Il comprend de nombreuses technologies pour aider les développeurs et les équipes de sécurité. Cela inclut l'analyse du code source (SAST), l'instrumentation qui peut tester votre application de "l'intérieur vers l'extérieur") IAST, la protection d'exécution (RASP) qui peut réellement neutraliser les attaquants qui tentent d'exploiter les vulnérabilités du jour zéro. Des exemples récents sont des choses comme Log4J et Spring4Shell. Et enfin, nous avons récemment introduit les premiers outils de sécurité au monde pour le code sans serveur natif du cloud. Nous serions heureux de discuter avec les gens des meilleures options pour créer un programme DevSecOps qui leur permettra de maintenir leur vitesse de développement, mais aussi de s'assurer que leur code est sécurisé. Vous pouvez contacter pour plus de détails . Mónica Freitas, sur le thème de la sécurité "en libre-service"... Les solutions de sécurité en libre-service font référence à la capacité des développeurs à tirer parti des outils Contrasts par eux-mêmes et à les utiliser comme bon leur semble. Cela signifie que les développeurs et les équipes DevOps peuvent obtenir uniquement les outils dont ils ont besoin pour faire le travail et peuvent trouver et corriger les vulnérabilités avec une formation minimale en sécurité (ou une surveillance constante d'une équipe d'ingénierie de sécurité dédiée). Quant à demander à Contrast des solutions sur mesure, absolument. Notre équipe est en mesure de guider les équipes sur ce qui fonctionnera le mieux en fonction de leurs objectifs ainsi que des besoins à long terme et à court terme. Steve Wilson, quels sont les problèmes de sécurité les plus courants que vous avez rencontrés et quelles mesures les entreprises peuvent-elles prendre pour les résoudre ? Mónica Freitas, merci pour la question sur les problèmes de sécurité les plus courants. Je vais éviter des choses comme le phishing et les mauvais mots de passe (car c'est un terrain évident et bien rodé). Au lieu de cela, je vais me concentrer sur les problèmes de création d'applications sécurisées. Il y a deux choses principales que vous devez regarder : sécuriser le code que vous écrivez et sécuriser le code que vous utilisez et que quelqu'un d'autre a écrit (généralement open-source). Avec le code que vous écrivez, il existe un assez grand nombre de types de vulnérabilités qui sont classés. L'une des plus courantes (et des plus graves) est appelée crise d'"injection". Cela signifie qu'une entité extérieure (un pirate !) est capable de mettre des données dans une partie de votre système d'une manière que vous n'aviez pas anticipée ou voulue. Celles-ci peuvent être des choses comme une "attaque par injection SQL" où un pirate est capable de mettre un morceau de langage de requête de base de données dans votre base de données et de l'exécuter à distance. C'est très courant et c'est un problème majeur depuis 20 ans. Un autre qui a souvent été considéré comme moins grave est "l'injection de fichier journal" où un pirate est capable de déposer des données contaminées directement dans un fichier journal de votre application. On dirait que ce n'est pas trop grave, mais c'était au cœur du récent incident de sécurité Log4J qui a touché tant d'entreprises en décembre/janvier. En ce qui concerne le code open source, nous savons que la majorité du code des applications professionnelles modernes n'est même pas écrite par les développeurs d'une entreprise. C'est open-source. Il est ouvert à toutes sortes d'attaques et bien que l'open source fournisse une base solide pour un code sécurisé en ayant de nombreux yeux sur le code, beaucoup de ces yeux sont maintenant des pirates (des étudiants aux pirates des États-nations). Certaines de ces bibliothèques (comme Struts, Log4J, Spring) sont si populaires qu'elles sont intégrées dans des millions d'applications à travers le monde. Il y a quelques années, l'agence de notation Equifax utilisait une version vulnérable de Struts et a perdu les données financières personnelles de centaines de millions d'Américains. En conséquence, ils ont été condamnés à une amende de plus de 400 000 000 dollars. C'est sérieux. La meilleure façon de gérer ces deux problèmes est de moderniser vos pratiques de développement pour inclure des outils automatisés qui vous aident à détecter et à résoudre ces types de problèmes. La plate-forme de code sécurisé de Contrast fonctionne avec Java, JavaScript .NET, Go, Ruby, Python, Scala et Kotlin, donc si vous utilisez l'une de ces technologies populaires, nous serions heureux de vous aider à moderniser vos outils et à créer un programme autour de l'automatisation de tous de cela. Salut Steve Wilson ! Je suis curieux, que sont les SBOM ? Peuvent-ils impacter les systèmes de sécurité ? Sara Pinto, merci d'avoir posé des questions sur SBOM. Un domaine tellement intéressant et d'actualité en ce moment! Cela fait vraiment partie du sujet plus large appelé Software Supply Chain Security. Comme indiqué dans certaines des autres questions de ce fil, une grande partie du code des applications modernes n'est pas écrite par les propres développeurs d'une entreprise. Il provient d'un tiers (souvent open-source). Il y a peu de temps, un fournisseur de logiciels appelé Solar Winds a été piraté. C'était mauvais pour les vents solaires, mais ce qui était pire, c'est que le code construit par Solar Winds était intégré dans les environnements de cloud et de centres de données de nombreuses autres entreprises et même des gouvernements. Sachant cela, les pirates qui ont attaqué SolarWinds ne se sont pas contentés de voler SolarWinds, ils ont profité de l'occasion pour placer des portes dérobées dans le logiciel de SolarWind qui serait ensuite intégré par de nombreuses autres sociétés. L'exploration a été massive et a conduit à l'idée que vous devez garder une trace de votre propre code, mais aussi du code que vous obtenez d'ailleurs. L'ensemble du processus doit être sécurisé de bout en bout et c'est ce qu'on appelle la sécurité de la chaîne d'approvisionnement logicielle. SBOMs représente la nomenclature du logiciel. Un SBOM est une liste de tous les composants open source et tiers présents dans une base de code en plus de toutes les licences qui régissent ces composants. Considérez-le comme les étiquettes nutritionnelles sur le côté d'une boîte de nourriture. Cela aide un consommateur à savoir ce qu'il y a dans les aliments afin qu'ils puissent l'utiliser pour s'assurer que les aliments sont sûrs et sains pour eux. Les SBOM peuvent créer plus de transparence sur le marché des logiciels et permettre également aux développeurs d'agir rapidement si une vulnérabilité a été identifiée. Le récent a déclaré que les SBOM devraient être nécessaires et la NTIA a publié un « » pour les incontournables de SBOM, et bon nombre de ces points n'ont été soulignés que dans et la d'information qui l'accompagne. . De plus, Gartner prédit que d'ici 2025, 60 % des organisations qui créent ou achètent des logiciels d'infrastructure critiques rendront obligatoires et normaliseront les SBOM dans leurs pratiques d'ingénierie logicielle. Bien qu'il s'agisse de premières étapes importantes pour sécuriser les applications modernes, y compris sans serveur, les développeurs et les équipes de sécurité doivent toujours assurer la sécurité de leurs applications, et cette responsabilité incombe aux équipes DevSecOps. Steve Wilson, à mesure que Web3 se développe, envisagez-vous la possibilité de créer des options de sécurité pour Web3 ? Mónica Freitas, merci pour la question sur la sécurité Web3. C'est un sujet FASCINANT et assez vaste. Je vais essayer d'ajouter mon point de vue. Tout d'abord, nous devons définir Web3. Dans la culture populaire, l'idée du Web3 est dominée par le commerce d'étranges œuvres d'art numérique. Il y a des discussions constantes sur les stratagèmes de Ponzi et la fraude. Mais je pense que les concepts du Web3 sont fascinants. Lorsque vous supprimez tout, Web3 est un ensemble audacieux de tentatives (et je suis sûr que beaucoup échoueront) pour reconstruire une grande partie d'Internet à partir de zéro. Pourquoi devons-nous faire cela? Eh bien, c'est vraiment une question de sécurité et de confiance ! Internet et le World Wide Web qui s'y trouve ont été construits par des universitaires pour des universitaires. Ils étaient destinés à ouvrir l'information, à faire progresser la science et la technologie et à promouvoir l'échange d'idées. En ce sens, Internet/web est l'entreprise la plus réussie de l'histoire de l'humanité.

Cependant, de par sa nature, il lui manque un concept clé : la confiance ! Comment puis-je savoir qui vous êtes ? Comment puis-je savoir ce que vous possédez ? Comment savoir à quoi vous avez droit ? Rien de tout cela n'a été intégré à Internet au départ. Tout ce qui se superpose à cela est fragile et contrôlé de manière centralisée. Comment puis-je savoir ce que vous possédez ? Je demande à votre banque/société de carte de crédit. Comment puis-je savoir qui vous êtes ? Wow, c'est un problème presque totalement non résolu sur Internet à ce jour !

Web3 a tendance à commencer par les concepts lancés par Bitcoin/Crypto-monnaie - avec Blockchain en son cœur. Il y a environ quatre ans, j'ai découvert que ma fille adolescente et ses amis utilisaient des services VPN gratuits pour traverser le pare-feu du lycée afin de pouvoir regarder Netflix à l'école. Plutôt que d'être en colère, j'ai trouvé que c'était un excellent moyen d'ouvrir une conversation avec elle sur la sécurité et la cryptographie (NERD DAD ALERT !). Nous avons en quelque sorte fini par nous lancer dans une fabuleuse aventure minière Ethereum et en apprendre davantage sur Blockchain. Vous pouvez lire certaines de nos aventures .

Cela m'a amené personnellement à vraiment plonger dans le fonctionnement de la Blockchain. À certains égards, c'est une merveille de l'informatique, et à certains égards, c'est un cauchemar d'ingénierie, mais il a lancé un nouvel ensemble de concepts sur la façon dont vous distribuez la confiance sans autorité centrale. C'est le cœur du web3 ! Comment puis-je savoir qui vous êtes et ce que vous possédez (dans un certain contexte) sans qu'une institution tierce au milieu ne me le dise ? Si vous souhaitez lire mes réflexions sur les avantages et les inconvénients de la blockchain, vous pouvez consulter cet . C'est vieux de quelques années, mais les concepts de base ici évoluent assez lentement pour que tout soit largement pertinent pour la discussion. Alors, passons maintenant aux trucs en laiton! Que dirais-je à quelqu'un qui cherche à se plonger dans la sécurité Web3 ? Premièrement, il existe des cas très médiatisés de défaillances de sécurité dans les petites chaînes de blocs. La confiance dans la blockchain est généralement basée sur le vote par consensus et si vous n'avez pas de masse critique, quelqu'un peut détenir plus de 50 % des votes et vous avez des problèmes. Cependant, je ne pense pas que ce soit le sujet le plus important pour les développeurs qui envisagent Web3 aujourd'hui. Quand je regarde les gros incidents de sécurité autour de Web3/NFT/Crypto ces dernières années, ils ne sont pas liés à la blockchain principale. Ils se trouvent autour des parties Web2 du code/de l'infrastructure d'une entreprise qui collent encore le monde ensemble. Le jeu Web3, à très long terme (pensez en termes de décennies), consiste à remplacer les fondements d'Internet par des éléments qui incluent la confiance comme élément central. Cela peut arriver, et c'est louable, mais c'est loin d'être le cas. Aujourd'hui, nous avons des choses comme IPv4/6, SSL, HTML, JavaScript, REST, AppServers, des bibliothèques open source et des bases de données SQL qui maintiennent le monde ensemble (avec des îlots de technologies blockchain/web3). Si vous gérez un échange NFT (ou quelque chose de similaire), je passerais autant (ou plus) de mon temps à m'inquiéter de la partie Web2 de mon monde qui est le lien entre moi et mes clients/partenaires. Il est sensible aux mêmes concepts de sécurité applicative dont nous avons déjà parlé ici. Vous avez besoin d'un excellent programme et d'une plateforme DevSecOps. Et la plupart d'entre eux devraient ressembler à un processeur de carte de crédit ou à une grande banque. Le contraste peut aider ici. Si vous pouvez durcir votre "colle" Web2 au même niveau qu'une grande banque, alors vous pouvez passer votre temps à vous soucier de la façon de vous différencier dans le monde Web3. C'est une période passionnante. J'ai hâte de voir comment cela va évoluer. Faites-moi savoir si vous voulez parler plus sur ce sujet. J'aimerais discuter ! Steve Wilson, je suis nouveau dans toutes ces normes de sécurité logicielle. Pourriez-vous les détailler ? Que dois-je savoir à ce sujet ? Sara Pinto, merci pour la question sur les normes de sécurité des logiciels. Ouah! Vous venez d'aborder un sujet vraiment vaste et important. Il existe en gros deux types de normes : contractuelles/commerciales et statutaires. Les normes commerciales sont des choses qui vous aideront à faire des affaires. Adhérer à l'une de ces normes peut être inscrit dans un contrat. Par exemple, votre client peut exiger que vous adhériez à une norme appelée SOC2 et que vous soyez régulièrement audité pour le démontrer. D'autre part, pour vendre des services de cloud computing au gouvernement américain, vous devez adhérer à un ensemble de normes appelées FedRAMP (c'est "par la loi", donc c'est considéré comme une exigence légale). Ces deux exemples sont intéressants et importants si vous dirigez une entreprise de logiciels/SaaS. Cependant, pour les développeurs individuels, ils sont vraiment abstraits. Par exemple, ces normes incluent de nombreux éléments bien au-delà du simple "logiciel". Un bon exemple serait, avez-vous des vérifications d'antécédents suffisantes et une formation de base en matière de sécurité pour tous vos employés ?

Pour les développeurs de logiciels, il existe des normes plus précises qui entrent beaucoup plus dans les détails dont vous voudrez peut-être vous soucier. Voici une liste partielle de choses amusantes à explorer pendant votre voyage ! Notez que certaines exigences sont techniques et certaines exigences sont les processus que vous utilisez pour créer des logiciels.

Décret exécutif sur la cybersécurité 14028

PCI SSF (Remplacé PA-DSS)

OWASP

NIST

CISA

OMB

Confidentialité (la sécurité est une condition préalable à la confidentialité

Autre

Cela a été super amusant pour tout le monde. Merci de nous avoir rejoint ! Je vais regarder cette chaîne pour le reste de la journée, mais si c'est la fin de fil, je vous laisse avec un petit quelque chose sur lequel j'ai travaillé. Je espère que vous l'apprécierez! Merci de nous avoir rejoint Steve Wilson, et pour vos réponses réfléchies. Nous avons adoré vous avoir ici!