Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Lorsque vous mettez en place la discipline de l’architecture de sécurité, cet article fournit des conseils sur la manière d’appliquer les 10 lois immuables du risque de sécurité sous forme de recommandations pratiques, à mesure que vous mettez en place et modernisez la discipline de l’architecture de sécurité.
Examiner les lois immuables de la sécurité
L’architecture existe pour identifier les exigences difficiles et les traduire en conseils actionnables pour réduire les risques de sécurité, limiter les dommages et maintenir les systèmes disponibles au fil du temps. À la base de ce travail sont les lois immuables de la sécurité.
Ces lois décrivent des vérités désagréables sur la sécurité qui vous aident à planifier un contrôle efficace, à éviter les idées fausses courantes qui sapent l’architecture de sécurité et créent des risques organisationnels.
| Droit immuable | Impact de l’architecture |
|---|---|
| 1. Si un mauvais acteur peut vous persuader d’exécuter leur programme, ce n’est pas votre ordinateur | L’exécution de code non autorisée entraîne une perte de contrôle. La prévention seule est insuffisante. |
| 2. Si un acteur incorrect peut modifier le système d’exploitation, ce n’est pas votre ordinateur. | La compromission du plan de contrôle est un risque systémique. Cela s’applique si le plan de contrôle est un système d’exploitation local, un système de gestion des identités, un outil de sécurité ou tout autre élément avec l’accès au niveau du système/racine. |
| 3. Si une personne malveillante a un accès physique illimité, ce n’est plus votre ordinateur | L’exposition physique doit être supposée, non traitée comme une exception. |
| 4. Si un acteur malveillant peut exécuter du contenu actif sur votre site Web, ce n’est plus votre site Web | Les frontières d’exécution définissent les frontières de confiance. |
| 5. Les mots de passe faibles l’emportent sur une sécurité renforcée | Les défaillances liées à l’identité mettent en échec les contrôles de sécurité multicouches. |
| 6. Un ordinateur est aussi sécurisé que son administrateur | L’accès privilégié est une priorité de sécurité critique. |
| 7. Les données chiffrées sont uniquement aussi sécurisées que sa clé de déchiffrement | Le chiffrement sans gouvernance est fragile. |
| 8. Un scanneur anti-programme malveillant obsolète est légèrement meilleur qu’aucun | Les défenses statiques se désintégrationnt. |
| 9. L’anonymat absolu n’est pas réalisable | La visibilité est inévitable. |
| 10. La technologie n’est pas une panacée | Il faut partir du principe que des défaillances humaines et des défaillances de processus se produiront. |
Appliquer les dix lois relatives au risque de cybersécurité
Même après avoir compris comment le contrôle de sécurité est potentiellement perdu et que l’impact sur l’architecture de sécurité n’est pas suffisant pour concevoir un système. Les architectes de sécurité doivent également comprendre :
- Quel est notre objectif d’optimisation ? - Où concentrons-nous nos efforts ? - Quels compromis sont acceptables ?
Pour déterminer ces questions, nous pouvons appliquer 10 lois courantes sur le risque de cybersécurité. Chaque ensemble de lois traite de différents aspects de la cybersécurité.
| Loi | Implication de l’architecture | Conseils de modernisation |
|---|---|---|
| 1. La réussite de la sécurité ruine le retour sur investissement de l’attaquant | Architectures de conception qui augmentent le coût de l’attaquant et réduisent le paiement, en particulier pour les ressources à valeur élevée. | - Concentrez les contrôles autour de l’identité, de l’accès privilégié et des données sensibles. - Réduire les zones d’approbation plate ; les systèmes segments de sorte que la compromission ne se met pas à l’échelle. - Hiérarchiser les protections qui interrompent les chaînes d’attaquants courantes, et non des cas spéciaux. |
| 2. Ne pas suivre le rythme, c’est prendre du retard | Les architectures statiques échouent. L’architecture doit supposer une évolution continue. | - L’architecture de sécurité n’est jamais terminée. Elle doit être opérationnellement durable et continuellement améliorée. - Conception pour la mise à jour continue (mise à jour corrective, configuration, stratégie). - Préférer les services cloud natifs et managés qui évoluent plus rapidement que les systèmes locaux ou sur mesure. - Assurez-vous que la visibilité et l’inventaire sont des exigences architecturales, et non des éléments ajoutés après coup. |
| 3. La sécurité est un enabler métier (productivité gagne toujours) | Si l’architecture crée des frictions, elle est contournée. | - Une bonne architecture de sécurité permet la productivité par défaut. - Favoriser l’accès basé sur l’identité par rapport à la complexité du réseau. - Intégrer des contrôles de sécurité dans des flux de travail utilisateur et développeur standard. - Rendre les chemins sécurisés les chemins les plus simples. |
| 4. Les attaquants s’en moquent | Les attaquants utilisent n’importe quel chemin d’accès disponible dans l’environnement. L’architecture doit éliminer les chemins les moins chers, et non défendre uniquement les chemins évidents. | - L’architecture doit refléter le comportement réel de l’attaquant, et non les croyances idéalisées dans les contrôles individuels. - Supposez une compromission par le biais de l’hameçonnage, de la mauvaise configuration ou des protocoles hérités. - Supprimer les points uniques architecturaux d’une défaillance catastrophique. - Assurer une protection contre l’ensemble du cycle de vie d’une attaque (mouvement latéral, réalisation des objectifs), et pas seulement contre l’accès initial. |
| 5. La priorisation impitoyable est une compétence de survie | Vous ne pouvez pas tout sécuriser. | - L’architecture consiste à choisir ce qu’il ne faut pas faire. - Identifiez les actifs les plus critiques et concevez une défense en profondeur autour de ceux-ci. - Accepter une assurance inférieure où l’impact sur l’entreprise est inférieur. - Utiliser des scénarios métier pour guider l’investissement architectural. |
| 6. La cybersécurité est un sport d’équipe | L’architecture doit intégrer le travail entre les disciplines et les équipes. | - Les architectes conçoivent la coordination, pas seulement les contrôles. - Aligner l’architecture avec les équipes de plateforme, les développeurs et les opérations. - Déléguer des contrôles aux plateformes qui peuvent les améliorer (fournisseurs de cloud, systèmes d’identité). - Évitez les solutions personnalisées où les services partagés suffisent. |
| 7. Votre réseau n’est pas aussi digne de confiance que vous pensez qu’il est | La confiance réseau ne doit jamais être le plan de contrôle principal, ni le seul. | - Cette loi sous-tend le déplacement de la conception centrée sur le périmètre. - Faire reposer les décisions de confiance sur le contexte de l’identité, de l’appareil et de l’application. - Architectures de conception qui supposent que le réseau est observable et hostile. - Conservez des contrôles effectifs tels que les pare-feu/pare-feu d’applications web (WAF), mais ne vous fiez pas à eux pour détecter/bloquer tout. - Utilisez des modèles d’accès Confiance nulle de manière cohérente dans l’ensemble des environnements. |
| 8. Les réseaux isolés ne sont pas automatiquement sécurisés | L’isolation est efficace uniquement lorsqu’elle est rigoureusement conçue et maintenue. | - Conserver l’isolation réseau qui donne de bons résultats. Assurez-vous de la maintenir et que les attaquants ne puissent pas facilement la contourner. - L’architecture doit prendre en compte les personnes et les processus, pas seulement la topologie. - Traitez l’isolation comme un système, et non comme une règle de filtrage réseau. - Sécuriser tous les points de pontage (média, accès du fournisseur, administrateurs). - Partir du principe qu’il y a compromission et appliquer des contrôles stricts liés à l’identité et aux opérations, même dans une conception à isolation physique. |
| 9. Le chiffrement seul n’est pas une solution de protection des données | La cryptologie n’est que aussi sécurisée que les clés qui le déverrouillent. | - Le chiffrement est important, mais est inefficace sans implémentation et opération sécurisées. - Architecturer la gestion centralisée des clés et la gouvernance des accès. - Protégez les mécanismes de déchiffrement avec la même rigueur que le stockage chiffré. - Combinez le chiffrement avec l’identité, la surveillance et l’application des stratégies. |
| 10. La technologie ne résout pas les problèmes de personnes et de processus | L’architecture doit partir du principe que les humains et les processus sont imparfaits. | - Moderniser l’architecture de sécurité pour réduire le rayon d’explosion d’une erreur humaine. Ne laissez pas un simple clic sur un e-mail de phishing compromettre votre posture de sécurité. - Concevoir des systèmes résilients à l’erreur. - Automatisez les garde-fous si possible. - Évitez les architectures qui dépendent d’une opération manuelle parfaite. |
Créer une architecture
En tant qu’architecte de sécurité, vous pouvez utiliser ces deux tables comme lentilles complémentaires. L’une pour valider la solidité technique et l’autre pour orienter la priorisation en fonction des risques. Lorsqu’elles sont combinées, elles forment un cadre de décision pratique pour la conception architecturale et la modernisation.
| Lois | Objectif | Utilisation architecturale | Questions avec réponse |
|---|---|---|---|
| Lois immuables de la sécurité | Identifiez les principes techniques qui sont toujours vrais. | Assurez-vous que les architectures ne violent pas la réalité technique. Hypothèses de test Validez les frontières de confiance. Évitez la fausse confiance. |
L’architecture est-elle fondamentalement saine ? La conception s’appuie-t-elle sur quelque chose qui peut facilement être contourné ? Supposons-nous que la technologie puisse compenser des administrateurs non fiables, des mots de passe faibles ou des méthodes d’accès physique ? Confondons-nous le chiffrement, l’isolation ou les outils avec un véritable contrôle ? |
| Lois relatives au risque de cybersécurité | Décidez ce qui compte le plus. | Identifiez où investir l’effort d’architecture. Élaborez des feuilles de route de modernisation. Justifier les compromis pour les dirigeants d’entreprises. |
Où les attaquants obtiennent-ils le plus gros paiement pour le moins d’efforts ? Quels contrôles modifient réellement le comportement de l’attaquant ? Quel travail ne vaut plus la peine de faire ? |
Example
Donc, si nous prenons un exemple qui utilise les deux tableaux ensemble.
| Décision de conception | Lentille de lois immuables | Le prisme des dix lois |
|---|---|---|
| Réduire la dépendance aux listes de contrôle d’accès réseau au profit d’un accès basé sur l’identité | Les réseaux ne sont pas dignes de confiance, l’identité compte. | Augmente le coût de l’attaquant et s’aligne sur les principes de Confiance nulle. |
| Hiérarchiser l’authentification multifacteur pour les administrateurs avant de renforcer les pare-feu de périphérie. | Des mots de passe faibles compromettent une sécurité renforcée. | Moyen le moins cher de briser les chaînes d’attaque courantes. |
| Segmenter les charges de travail au lieu de s’appuyer sur des « écarts d’air » | L’isolation n’est pas automatiquement sécurisée. | Réduit le rayon d’explosion lorsque les attaquants entrent. |
| Automatiser l’application des correctifs et la détection de la dérive de configuration | Les défenses obsolètes échouent. | Ne pas suivre, c’est prendre du retard |
L’utilisation conjointe de ces deux tableaux conduit à des architectures de sécurité qui :
- Supposez la compromission, concentrez-vous sur la réduction des risques et la limitation des dommages plutôt que sur la prévention absolue prometteuse.
- Concentrez-vous sur l’identité, les privilèges et le mouvement latéral, pas seulement sur la défense de périmètre.
- Supposons le changement continu et l’évolution, et non les diagrammes statiques.
- Équilibrez la productivité de l’entreprise avec la réduction des risques. Aligner les contrôles de sécurité sur la valeur métier.
- Intégrer des personnes, des processus et des technologies.
- Réduisez le retour sur investissement de l’attaquant au lieu de poursuivre une sécurité parfaite.
- Appliquez les principes Confiance nulle de bout en bout.
Étapes suivantes
Veillez à passer en revue les autres disciplines de sécurité.