La plupart des groupes vivent au quotidien des transformations digitales structurantes. L’objectif est de développer le business avec des outils performants et sécurisés, de le faire vite, avec agilité et en maitrisant les coûts. Il faut créer de la valeur et la protéger. La sécurité doit évidemment accompagner cette transformation, sans la freiner mais avec des garanties que les risques sont traités et sous contrôle. On a de plus en plus besoin de professionnels de la sécurité qui participent activement aux phases de conception et de développement afin d’intégrer la sécurité de manière continue aux différents projets. Le travail des architectes sécurité est facilité si un cadre méthodologie est défini et adapté aux besoins et au contexte business de l’entité. Cet article examine comment utiliser le référentiel SABSA pour mettre en place ce cadre et faciliter le travail des architectes sécurité au sein des programmes de transformation (migrations vers des plateformes Cloud publics et privés, agilité dans les cycles de développement logiciel, initiatives « big data », test des technologies blockchain, utilisation des containers, développement d’API pour automatiser l’orchestration…).

Le référentiel SABSA

Issu du monde anglo-saxon, SABSA est une marque déposée par SABSA Institute. Cette méthodologie fait partie du domaine ESA (Entreprise Security Architecture) de la sécurité. Elle n’est pas nouvelle et fait partie depuis longtemps du programme du CISSP, abordée dans le domaine 1. Elle se concentre sur les aspects sécurité de manière similaire à ce que l’on trouve pour les architectures d’entreprise globales (non spécifique à la sécurité), comme TOGAF par exemple. Le principal avantage de SABSA est son modèle en couches, centré sur les risques, aisément modulable. La méthodologie donne plusieurs visions : métier (le décisionnaire), conceptuelle (les objectifs et les risques), architecture logique (informations, processus, applications, interactions), physique (données, mécanismes de transfert, infrastructure), composants (outils, produits, technologies, standards) et enfin une vision transverse de gestion du « run », incluant les services de sécurité. SABSA comprend une vue « Assurance » pour les processus d’audits et de contrôles indépendants. Pour chaque couche, on doit répondre aux questions Quoi ? Pourquoi ? Comment ? Qui ? Où ? et Quand ? Par exemple, pour la couche « design » (architecture logique) pourront être déterminés les points liés à la classification de l’information, la méthode d’analyse et de traitement des risques, la cartographie des flux applicatifs et des échanges de données, les aspects IAM (Identity and Access Management), les domaines de confiance et leurs localisations, la planification.

Les architectes sécurité

L’architecte sécurité est généralement intégré aux équipes « design » soit dans les cellules d’intégration pour les projets d’infrastructures, soit dans les équipes de développement pour les projets applicatifs. Il doit être force de proposition afin de trouver des compromis acceptables entre les exigences de fonctionnement, de performance et les protections à prévoir. Par exemple, dans le cadre d’une migration d’applications « on-premise » vers un Cloud public, il devra analyser et adapter les solutions liées à l’authentification et à la gestion des identités ainsi que l’architecture des services de sécurité (services de cryptographie, Web Application Firewall, Intrusion Detection Prevention System, anti-Distributed Denial of Service…). Il devra avoir de solides compétences d’architecture lié à la solution Cloud (AWS, Azur, Google, OVH…), connaitre les briques et les configurations possibles des services sécurité proposés par le fournisseur Cloud, proposer des choix pertinents par rapport aux solutions historiques on-premise de l’entreprise ou les services sécurité des « pure players ».

Définir le cadre méthodologique

SABSA peut être utilisé pour définir un cadre méthodologique concret. Il permettra aux architectes de gagner du temps et de s’appuyer sur un formalisme défini, connu et validé au sein de son entité. Ce cadre pourra par exemple décrire :

• Le catalogue des briques disponibles pour les services d’authentifications (par exemple, cas d’approbations entre les annuaires, utilisations de SAML, les types d’authentifications en fonction des risques ou de la sensibilité des informations).
• La gestion de la cryptographie (l’organisation, les possibilités de gestion centralisée des clés par exemple avec KMIP, l’utilisation des Hardware Security Module dans le Cloud, les types de chiffrement possibles en fonction des risques, les cas de pseudo-anonymisation…), autant d’aspects largement abordés dans les certifications individuelles Sécurité Cloud CCSP ou CSSK.
• Les types d’analyse de risques à conduire en fonction du projet avec le niveau de détail souhaité (méthode quantitative ou qualitative, les cas d’évaluation de la sécurité par des audits techniques, les livrables, les responsabilités et le processus).
• L’intégration de la sécurité dans le cycle de développement Agile (répartition des rôles entre le « product owner », le « scrum master », l’équipe de développement et les experts sécurité, comment et quand intégrer la sécurité dans les réunions « Sprint Planning » et les « daily Scrum », les standards applicables, les outils automatiques disponibles…).
• Les niveaux d’audits internes et le suivi des plans de remédiation (responsabilités, niveaux de risques, priorités, modalités de clôture d’une action, indicateurs…).

Sans chercher la perfection, la définition, même ébauchée, de ce cadre évitera aux équipes d’architectes sécurité de se poser les mêmes questions à chaque projet. Elle apportera plus de visibilité aux responsables de programmes et permettra à la sécurité d’être mieux reconnue pour ce rôle d’accompagnateur plutôt que pour sa fonction historique de censeur. C’est un investissement initial très rentable pour la protection des données de l’entreprise. Comme tout cadre, il faut chercher à l’adapter à l’entité et son contexte, avec pragmatisme et en visant la simplicité.

 

 Pour en savoir plus sur les 20 meilleures formations sur la sécurité des systèmes d’information, téléchargez gratuitement notre livre blanc ci-dessous :