Click here for the english version
SIRTFI
Problématique
Le développement et l’inter-connexion des fédérations via eduGain a créé un nouveau vecteur d’attaque. Un compte compromis peut aujourd’hui potentiellement donner accès à une multitude de services au sein de la communauté.
Ce nouveau vecteur d'attaque s'inscrit dans un contexte où la prise en compte de la sécurité opérationnelle est variable selon les organisations et n’est souvent pas connue des autres participants. Un niveau de sécurité minimal n’est par exemple pas requis pour rejoindre une fédération. Dans le cas d’un incident de sécurité lié à la fédération, il n’y a donc aucune garantie d’une collaboration efficace entre les organisations concernées.
Le framework SIRTFI (Security Incident Response Trust Framework for Federated Identity) vise à fournir un cadre permettant d’une part, d’identifier les participants de confiance de la fédération et d’autre part, de garantir une collaboration efficace entre les entités lors d’une réponse à un incident de sécurité lié à la fédération.
Principe
Le framework SIRTFI définit un ensemble de règles et bonnes pratiques sécurité articulées autour des quatre domaines suivants : sécurité opérationnelle, réponse sur incident, traçabilité et responsabilité des participants.
Il existe aujourd'hui deux versions distinctes de cette spécification. L'ensemble de la documentation est accessible ici, et les documents normatifs sont les suivantes:
Les différences entre les deux versions sont résumées dans ce document. Hormis les reformulations mineures correspondant à des clarifications, ou de changements d'identifiants pour les règles, la seule véritable nouveauté correspond à l'ajout d'une obligation de notification, en plus de l'obligation de réponse (règle IR3). Elles sont cumulatives, c'est-à-dire que la conformité à la version 2 implique la conformité à la version 1.
Le tableau suivant dresse une description synthétique du contenu de chacune des thématiques:
Domaine | Description |
---|---|
Sécurité Opérationnelle [OS] | - Application régulière des patchs de sécurité - Processus de gestion des vulnérabilités - Détection d’intrusion et protection des systèmes - Possibilité d’intervention sur les droits d’accès utilisateur - Possibilité de contacter les propriétaires et utilisateurs d’un service au sein de l’organisation - Capacité de réponse sur incident |
Réponse sur incident [IR] | - Identification des contacts sécurité référents pour l’organisation - Réponse rapide aux demandes d’assistance des autres membres SIRTFI - Collaboration pour la résolution d’incidents de sécurité - Respect des procédures de réponse sur incident de l’organisation - Respect de la vie privée des utilisateurs - Utilisation du protocole TLP (Traffic Light Protocol) |
Traçabilité [TR] | - Politique de gestion des logs appropriée au sein de l’organisation permettant leur exploitation pour la résolution d’incidents de sécurité |
Responsabilité des Participants [PR] | - Politique d’utilisation acceptable du service (Acceptable Use Policy) en vigueur au sein de l’organisation - AUP connue des utilisateurs finaux |
Déclaration de conformité
Le chapitre qui suit décrit les étapes à suivre par une organisation afin de pouvoir déclarer une entité SAML conforme à SIRTFI.
Étape 1: auto-évaluation
La première étape pour une organisation consiste à s'auto-évaluer en prenant le framework SIRTFI comme cadre de référence (cf. chapitre précédent). Étant donné qu'il s'agit d'un engagement formel vis-à-vis d'autres organisations, cette auto-évaluation est censée être réalisée (ou du moins validée) par une autorité compétente à cet égard, typiquement le RSSI .
Dans le cas où l'évaluation est positive, l'organisation peut alors déclarer cette conformité SIRTFI pour chacune des ressources fédérées (IdP ou SP) dont elle est responsable. Cette opération est réalisée au travers du guichet de la fédération.
Étape 2: désignation d'un contact sécurité
Le contact sécurité d’une entité SAML sera le point de contact de référence dans le cas d’un incident de sécurité lié à la fédération impliquant cette entité. Il doit s'agir d'une personne ou un groupe de personnes (équipe, service) ayant accepté de respecter les obligations de notification et de réponse sur incident définies dans la spécification.
Étape 3: déclaration de conformité
La déclaration de conformité SIRTFI pour une entité SAML (IdP ou SP) s'effectue via le guichet de la fédération, depuis la page d'édition de l'entité concernée.
Au niveau de l'onglet “conformité” de l'entité, il suffit simplement de cocher la case prévue à cet effet, afin d'attester que cette ressource est bien conforme. Après avoir coché la case, il est alors obligatoire de renseigner le contact sécurité.
Une fois les modifications soumises, les métadonnées de l'entité seront modifiées pour signaler explicitement sa conformité. Les détails techniques sont indiqués en annexe.
Utilisation
Déclarer une ou plusieurs entités SAML conforme à SIRTFI implique de participer et collaborer à la résolution d'incidents de sécurité:
- Si vous constatez un incident de sécurité impliquant une entité de la fédération, vous devez contacter le contact sécurité correspondant listé dans les méta-données associées à cette entité ;
- Inversement, si vous êtes sollicités pour aider à la résolution d’un incident de sécurité, vous devez répondre et activement collaborer avec les autres organisations/entités conformes SIRTFI.
En dehors de ces procédures, il est également possible de mettre à profil la signalisation explicite des entités conformes à SIRTFI dans les métadonnées, pour leur accorder un niveau de confiance supérieur aux autres:
- un fournisseur d'identité peut choisir d'authentifier ses utilisateurs uniquement pour des fournisseurs de service conformes
- un fournisseur d'identité peut choisir de diffuser certains attributs uniquement pour des fournisseurs de service conformes
- un fournisseur de service peut choisir de n'accepter des utilisateurs que depuis des fournisseurs d'identité conformes
Cette fiche technique présente ainsi plusieurs techniques correspondant à ce dernier cas.
Ces possibilités techniques ne sont pas forcément compatibles avec les conditions d'usage d'une fédération publique comme la Fédération Education/Recherche, et toute restriction d'accès doit être explicitement signalée aux utilisateurs potentiels.
Signalisation dans le métadonnées
La conformité SIRTFI est exprimée dans les métadonnées via l’utilisation de l'attribut d'entité urn:oasis:names:tc:SAML:attribute:assurance-certification
, et par la mention d'un contact sécurité, comme illustré ci-dessous pour une entité conforme aux versions 1 et 2:
<md:EntityDescriptor...> <md:Extensions> <mdattr:EntityAttributes> <saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oasis:names:tc:SAML:attribute:assurance-certification"> <saml:AttributeValue>https://refeds.org/sirtfi2</saml:AttributeValue> <saml:AttributeValue>https://refeds.org/sirtfi</saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> </md:Extensions> ... <md:ContactPerson contactType="other"remd:contactType="http://refeds.org/metadata/contactType/security"> <md:GivenName>Security Response Team</md:GivenName> <md:EmailAddress>mailto:security@xxxxxxxxxxxxxxx</md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>