Documenter et centraliser les diagrammes d'architecture

Pour réagir rapidement et avec précision à un événement de sécurité, vous devez comprendre l'architecture de vos systèmes et réseaux. La compréhension de ces modèles internes est non seulement importante pour la réponse aux incidents, mais également pour vérifier la cohérence entre les applications avec lesquelles les modèles sont conçus, conformément aux meilleures pratiques. Vous devez également vérifier que cette documentation est à jour et régulièrement mise à jour conformément aux nouveaux modèles d'architecture. Vous devez développer une documentation et des référentiels internes détaillant des éléments tels que :

• AWS structure du compte - Vous devez savoir :

  • Combien de AWS comptes possèdes-tu ?

  • Comment sont organisés ces AWS comptes ?

  • Qui sont les propriétaires commerciaux des AWS comptes ?

  • Utilisez-vous les politiques de contrôle des services (SCPs) ? Dans l'affirmative, quels sont les garde-fous organisationnels mis en œuvre en utilisant ? SCPs

  • Limitez-vous les régions et les services qui peuvent être utilisés ?

  • Quelles sont les différences entre les unités commerciales et les environnements (dev/test/prod) ?

• AWS modèles de service

  • Quels AWS services utilisez-vous ?

  • Quels sont les AWS services les plus utilisés ?

• Modèles d'architecture

  • Quelles architectures cloud utilisez-vous ?

• AWS modèles d'authentification

  • Comment vos développeurs s'authentifient-ils généralement ? AWS

  • Utilisez-vous des rôles ou des utilisateurs IAM (ou les deux) ? Votre système d'authentification est-il AWS connecté à un fournisseur d'identité (IdP) ?

  • Comment associer un rôle ou un utilisateur IAM à un employé ou à un système ?

  • Comment l'accès est-il révoqué lorsqu'une personne n'est plus autorisée ?

• AWS modèles d'autorisation

  • Quelles sont les politiques IAM utilisées par vos développeurs ?

  • Utilisez-vous des politiques basées sur les ressources ?

• Journalisation et surveillance

  • Quelles sources de journalisation utilisez-vous et où sont-elles stockées ?

  • Agrégez-vous AWS CloudTrail les journaux ? Dans l'affirmative, où sont-ils conservés ?

  • Comment interrogez-vous CloudTrail les journaux ?

  • Amazon est-il GuardDuty activé ?

  • Comment accèdez-vous aux GuardDuty résultats (par exemple, console, système de billetterie, SIEM) ?

  • Les résultats ou les événements sont-ils agrégés dans un SIEM ?

  • Les tickets sont-ils créés automatiquement ?

  • Quels sont les outils mis en place pour analyser les journaux dans le cadre d'une enquête ?

• Topologie du réseau

  • Comment les appareils, les points de terminaison et les connexions de votre réseau sont-ils organisés physiquement ou logiquement ?

  • Comment se connecte votre réseau AWS ?

  • Comment le trafic réseau est-il filtré entre les environnements ?

• Infrastructures externes

  • Comment sont déployées les applications orientées vers l'extérieur ?

  • Quelles AWS ressources sont accessibles au public ?

  • Quels AWS comptes contiennent des infrastructures orientées vers l'extérieur ?

  • Quel DDo type de filtrage S ou externe existe-t-il ?

La documentation des schémas techniques et des processus internes facilite le travail de l'analyste de réponse aux incidents, en l'aidant à acquérir rapidement les connaissances institutionnelles nécessaires pour répondre à un événement de sécurité. Une documentation complète des processus techniques internes simplifie non seulement les enquêtes de sécurité, mais permet également de rationaliser et d'évaluer les processus.