La sécurité dès la conception (SbD) expliquée
La sécurité dès la conception est une approche de développement logiciel qui vise à faire de la sécurité un pilier, et non une réflexion après coup, c’est-à-dire l’intégration des contrôles de sécurité dans les produits logiciels dès la phase de conception. SbD crée des logiciels sécurisés que les entreprises peuvent déployer sans encourir de coûts supplémentaires pour les fonctionnalités de sécurité.
Pour mieux comprendre le SbD, imaginez un scénario où vous devez construire un entrepôt sécurisé pour vos marchandises de plusieurs millions de dollars. Vous pouvez construire un bâtiment avec du bois facile à percer, le fortifier avec des éléments de sécurité, par exemple des capteurs et des caméras de surveillance, et même embaucher une entreprise de sécurité. Ou vous pouvez construire votre entrepôt en briques, utiliser des portes en métal lourd et installer les mêmes caractéristiques de sécurité.
L’entrepôt en briques sera, bien sûr, plus sûr, car quelles que soient vos caractéristiques de sécurité, il est préférable d’avoir un système inviolable, et c’est l’approche qui illustre SbD.
The Secure Coding Best Practices [Cheat Sheet]
With curated insights and easy-to-follow code snippets, this 11-page cheat sheet simplifies complex security concepts, empowering every developer to build secure, reliable applications.
Download Cheat Sheet
Pourquoi la sécurité dès la conception ?
Auparavant, les applications Web étaient vulnérables dès leur conception, car les fournisseurs de logiciels livraient des logiciels avant d’y intégrer la sécurité. Cela signifiait que les entreprises devaient acheter des fonctionnalités de sécurité en tant que modules complémentaires et corriger les vulnérabilités majeures au fur et à mesure qu’elles se présentaient, une approche rentable pour les fournisseurs, car plus de fonctionnalités équivalait à plus d’argent.
Mais en tant que principales cibles des attaques de la chaîne d’approvisionnement, les entreprises sont celles qui font face aux conséquences juridiques, financières et réputationnelles en cas de violation (et c’est souvent le cas).
SbD s’attaque à ce problème « pénaliser l’utilisateur de l’entreprise, épargner le fournisseur » en promouvant une culture de développement de logiciels où l’utilisateur et le fournisseur sont tenus responsables de leurs actions ou inactions. Cela améliore à la fois les logiciels des fournisseurs et des utilisateurs Posture de sécurité en réduisant leur surface d’attaque et en facilitant d’autres résultats clés.
Correctifs plus faciles et moins coûteux
L’application urgente de correctifs de sécurité pendant l’utilisation du logiciel (pour prévenir les violations de données et les dommages financiers et de réputation associés) peut être pénible, coûteuse et truffée d’erreurs.
Les produits conçus pour être sécurisés dès le départ nécessitent moins de correctifs et moins critiques, ce qui rend le processus beaucoup moins coûteux et plus facile.
Produits économiques
La seule façon de sécuriser les systèmes vulnérables de par leur conception est d’ajouter plusieurs modules complémentaires. Cependant, les attaquants peuvent toujours exploiter le portes dérobées créé par la faille VbD pour infiltrer les systèmes.
Sécuriser les systèmes par défaut est plus rentable que de faire face à un risque plus élevé de violations de données et de coûts, de poursuites et d’amendes associés.
Conformité réglementaire
Étant donné que les logiciels développés à l’aide de l’approche SbD sont axés sur la sécurité, ils sont plus susceptibles d’être conformes par défaut. Cela facilite le processus de vérification des différents composants logiciels pour s’assurer que conformité avec diverses réglementations.
Comment fonctionne la sécurité dès la conception ?
L’approche SbD comporte quatre étapes clés, que nous explorons ci-dessous.
Étape 1 : Définir les exigences de sécurité
SbD commence par une étude claire du logiciel à développer, de ses vulnérabilités potentielles et des exigences de sécurité correspondantes. Pour un service de base de données, les exigences de sécurité incluent le chiffrement, le contrôle d’accès basé sur les rôles (RBAC) et d’autres techniques d’autorisation.
Étape 2 : Effectuer des évaluations des risques et modéliser les menaces
Cette étape implique l’utilisation d’un Scanner de vulnérabilité pour cartographier les chemins d’attaque potentiels du logiciel.
Par exemple, un fournisseur de services de base de données est exposé à des chemins d’attaque possibles tels que des adresses IP publiques ou des comptes privilégiés en raison d’informations personnelles identifiables (PII) sensibles et d’informations de santé protégées (PHI) stockées dans ses bases de données.
Free Cloud Risk Assessment
Connect with a Wiz expert for a personal walkthrough of the critical risks in each layer of your environment.
Request Assessment
Étape 3 : Écrire du code et construire des mesures de sécurité simultanément
À ce stade, l’équipe d’ingénieurs abandonne les procédures de codage conventionnelles pour développer des logiciels avec des Mesures de sécurité. Pour le fournisseur de base de données, cela peut inclure l’écriture de code qui :
Empêche par défaut l’ouverture au public des bases de données
Valide automatiquement les entrées de l’utilisateur sans que les utilisateurs d’entreprise aient à acheter des modules complémentaires
Nécessite plusieurs mécanismes d’authentification avant qu’une forme d’accès ne soit accordée
Limite les points d’accès pour les comptes privilégiés
Étape 4 : Surveillance et correctif en continu
Enfin, le logiciel est testé et, s’il s’avère sécurisé par sa conception, il est expédié. Au fur et à mesure que les utilisateurs déploient le logiciel, le fournisseur surveille, audite et envoie en permanence des mises à jour SbD à mesure que les nouvelles menaces et les Vulnérabilités émerger.
Principes de sécurité dès la conception
La Cybersecurity and Infrastructure Security Agency (CISA) encourage les fabricants de logiciels à adopter trois principes fondamentaux lors du développement d’un produit.
Responsabilité partagée
Tant le vendeur que le client devrait partager le fardeau de la sécurité. Les fabricants de logiciels doivent créer des produits sécurisés et appliquer régulièrement des correctifs à leurs logiciels au fur et à mesure de l’évolution du paysage des menaces. Les clients, quant à eux, sont censés configurer leurs produits à l’aide de ce logiciel en toute sécurité et protéger leurs données.
Transparence radicale
Les fabricants de logiciels doivent partager des informations sur ce qui rend leurs produits sécurisés dès la conception. Ils sont responsables devant leurs clients de la précision des avis de vulnérabilité, des enregistrements CVE (Common Vulnerability and Exposure) associés et des mécanismes d’authentification, pour ne citer que quelques-uns des éléments attendus d’un produit SbD.
Structure organisationnelle
La collaboration est essentielle entre les fournisseurs et les clients, ainsi qu’entre les développeurs et les équipes de sécurité. Cela facilitera la mise en œuvre de contrôles de sécurité quasi impénétrables et permettra une planification budgétaire et une allocation des ressources basées sur des informations.
Les défis de la mise en œuvre de la sécurité dès la conception
Discutons de trois principaux défis de l’adoption du SbD.
| Challenge | Description |
|---|---|
| Short-term costs vs. long-term profits | The cost of restructuring legacy software and switching programming languages to embed security—rather than bolt it on—is discouraging for most vendors. Even in modern systems, embedding security is a complex and costly process. Still, in the long run, fewer and less complicated patches, fewer attacks, etc. will mean the initial cost pays for itself. |
| Marketability | The motivation—for cloud vendors—to implement SbD is low, as there are no direct monetary returns for them. It is difficult to market restructured SbD products on the “now secure-by-design” premise, as this will leave enterprise users with the presupposition that the products weren’t properly built and secured earlier on. It is easier to sell legacy software as is, alongside aftersales/add-on security products like firewalls and antivirus. |
| Third-party vendor liability | An important implication of SbD is that software vendors are liable for supply chain vulnerabilities. For example, a single security flaw can affect several enterprise customers who would want the vendor to take the blame, i.e., face the financial and reputational consequences. Getting all parties onboard with the shared responsibility model is thus critical, as discussed above. This makes it clear that security is in fact a shared burden between the vendor and the customer. |
Bonnes pratiques en matière de sécurité dès la conception
La CISA propose quelques tactiques de SbD tirées de la Cadre de développement logiciel sécurisé (SSDF) du National Institute of Standards and Technology (NIST) : SP 800-218. Les organisations doivent intégrer ces pratiques à chaque étape de leur cycle de développement logiciel (SDLC).
Utiliser des composants logiciels sécurisés
Déployez des composants logiciels bien sécurisés, y compris des bibliothèques, des frameworks et des middlewares, uniquement à partir de fournisseurs vérifiés. Évitez également les logiciels présentant des vulnérabilités connues, notamment les défaillances cryptographiques et d’authentification, les contrôles d’accès défaillants, les vulnérabilités d’injection et les problèmes de journalisation.
Une plate-forme de protection des applications cloud native (Crédit : CNAPP) sera utile pour détecter les composants non sécurisés.
Adopter les bonnes pratiques de conception
Les organisations peuvent réduire les risques pour leurs systèmes logiciels en mettant en œuvre une défense en profondeur, c’est-à-dire : avoir plus d’une couche de mesures de sécurité. Pendant ce temps, le sandboxing isole les logiciels et les composants de sécurité pour éviter que la compromission d’un seul composant n’affecte l’ensemble du système.
Les fournisseurs doivent également concevoir des logiciels qui facilitent l’application des correctifs ; La réduction des temps d’arrêt résultant des mises à jour logicielles encouragera les utilisateurs de l’entreprise à appliquer les correctifs plus rapidement.
Utiliser des langages de programmation sécurisés pour la mémoire
Le NIST encourage Développeurs pour mettre en œuvre des mesures d’atténuation courantes ciblées sur la mémoire, telles que l’intégrité du flux de contrôle (CFI) et la randomisation de la disposition de l’espace d’adressage (ASLR). Mais au-delà de cela, le NIST note également qu’ils devraient adopter des langages modernes à mémoire sûre, par exemple, Rust, Go, Java, C#, Swift et Python, tout en évitant leurs homologues dont la mémoire n’est pas sécurisée, C et C++.
Cela permettra d’atténuer les vulnérabilités de sécurité de la mémoire telles que SlammerWorm, Ghost Engine et Stagefright.
Adoptez des requêtes paramétrées et des frameworks de modèles web
Les requêtes paramétrées sont des requêtes SQL avec des paramètres qui séparent l’entrée utilisateur de la requête elle-même. Les frameworks de modèles Web contiennent des informations contextuelles qui empêchent automatiquement les entrées suspectes de l’utilisateur. Ensemble, ces mécanismes permettent d’éviter l’injection SQL et Attaques par script intersite (XSS).
Fournir des SBOM
Les fournisseurs de logiciels doivent fournir aux utilisateurs une liste des composants logiciels, des bibliothèques et des outils propriétaires et tiers qu’ils ont utilisés pour développer des logiciels. Cette liste, qui peut être générée via un Scanner SBOM sans agent: permet une résolution facile des vulnérabilités.
Éliminez les mots de passe par défaut
Les fournisseurs doivent éviter de déployer des produits avec des mots de passe par défaut. Au lieu de cela, ils doivent adopter l’authentification multifactorielle et exiger des utilisateurs qu’ils définissent des mots de passe forts immédiatement après avoir configuré le logiciel.
Fournir des profils d’autorisation logicielle
Ces profils désignent des rôles d’utilisateur et des cas d’utilisation pour limiter l’accès inutile aux données utilisateur et aux comptes privilégiés. Les fabricants de logiciels doivent fournir des profils d’autorisation de logiciels détaillés, mettre en œuvre le principe du moindre privilège et émettre des avertissements contre tout écart par rapport aux limites désignées.
Conclusion
La sécurité dès la conception met en œuvre de manière proactive des protocoles de sécurité dès la conception du logiciel. Soutenu par la CISA et d’autres acteurs clés de l’industrie, SbD encourage la réalisation d’évaluations des vulnérabilités, d’analyses de chemins d’attaque et d’analyses de composants logiciels afin de déterminer et de résoudre les vulnérabilités logicielles potentielles avant la livraison des applications et à chaque étape du SDLC.
L’objectif est d’éliminer les outils de sécurité coûteux et les modifications compliquées du code après-vente qui ne protègent pas adéquatement les systèmes contre les attaques, car ils sont déjà vulnérables de par leur conception.
SbD est une approche moins coûteuse, plus rapide et plus robuste de la création et de la sécurisation des applications. C’est pourquoi Wiz est l’un des principaux défenseurs de Code de sécurité d’expédition. Sa solution :
Facilite la visibilité logicielle de bout en bout
Fournit des SBOM à jour
Permet Analyse du chemin d’attaque
Inscrivez-vous à un Démo personnalisée pour voir comment Wiz peut vous aider à commencer votre transition vers des produits sécurisés dès la conception.
See for yourself...
Learn what makes Wiz the platform to enable your cloud security operation
