HAL Id: tel-01538386
https://tel.archives-ouvertes.fr/tel-01538386
Submitted on 13 Jun 2017HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
policies
Nghi Huynh
To cite this version:
Nghi Huynh. Verification and validation of healthcare access control policies. Computation and Language [cs.CL]. Université Paris-Est; Université de Sherbrooke (Québec, Canada), 2016. English. �NNT : 2016PESC1042�. �tel-01538386�
CONTRÔLE D’ACCÈS DANS LE DOMAINE MÉDICAL.
par
Nghi Huynh
Thèse en cotutelle présentée
en vue de l’obtention du grade de philosophiæ doctor (Ph.D.)
soutenue le 6 Décembre 2016
Jury :
Président :
Yves LEDRU
Rapporteur :
Kamel ADI
Rapporteur :
Jean-Paul BODEVEIX
Examinateur :
André MAYERS
Examinateur :
Catalin DIMA
Directeur de recherche :
Marc FRAPPIER
Directrice de recherche : Amel MAMMAR
Directrice de recherche : Régine LALEAU
le jury a accepté la thèse de Monsieur Nghi HUYNH dans sa version finale.
Membres du jury Professeur Marc FRAPPIER
Directeur de recherche Département Informatique Université de Sherbrooke, Canada
Amel MAMMAR Directrice de recherche Télécom Sud-Paris, France Professeur Régine LALEAU
Directrice de recherche Département Informatique, LACL Université Paris-Est Créteil, France
Professeur Catalin DIMA Membre interne
Département informatique, LACL Université Paris-Est Créteil, France
Professeur André MAYERS Membre interne Département Informatique Université de Sherbrooke, Canada
Professeur Yves LEDRU Membre externe
Université du Québec en Ouataouais, France Professeur Jean-Paul BODEVEIX
Rapporteur
Dans le domaine médical, la numérisation des documents et l’utilisation des dos-siers patient électroniques (DPE, ou en anglais EHR pour Electronic Health Record) offrent de nombreux avantages, tels que le gain de place ou encore la facilité de recherche et de transmission de ces données. Les systèmes informatiques doivent re-prendre ainsi progressivement le rôle traditionnellement tenu par les archivistes, rôle qui comprenait notamment la gestion des accès à ces données sensibles. Ces der-niers doivent en effet être rigoureusement contrôlés pour tenir compte des souhaits de confidentialité des patients, des règles des établissements et de la législation en vigueur.
SGAC, ou Solution de Gestion Automatisée du Consentement, a pour but de
fournir une solution dans laquelle l’accès aux données du patient serait non seulement basé sur les règles mises en place par le patient lui-même mais aussi sur le règlement de l’établissement et sur la législation. Cependant, cette liberté octroyée au patient est source de divers problèmes : conflits, masquage des données nécessaires aux soins ou encore tout simplement erreurs de saisie. C’est pour cela que la vérification et la validation des règles d’accès sont cruciales : pour effectuer ces vérifications, les méthodes formelles fournissent des moyens fiables de vérification de propriétés tels que les preuves ou la vérification de modèles.
Cette thèse propose des méthodes de vérification adaptées à SGAC pour le pa-tient : elle introduit le modèle formel de SGAC, des méthodes de vérifications de propriétés telles l’accessibilité aux données ou encore la détection de document inac-cessibles. Afin de mener ces vérifications de manière automatisée, SGAC est modélisé en B et Alloy ; ces différentes modélisations donnent accès aux outils Alloy et ProB, et ainsi à la vérification automatisée de propriétés via la vérification de modèles ou
model checking.
Mots-clés: Contrôle d’accès, méthodes formelles, sécurité, protection des données,
En tout premier lieu, j’aimerais remercier mes co-directeurs de thèse pour leur en-cadrement. Je tiens à remercier le professeur Marc Frappier qui m’a permis d’embar-quer dans cette grande aventure. Sa bonne humeur et sa motivation m’ont été d’une aide précieuse dans les phases difficiles de la thèse. Je souhaite également remercier la professeure Régine Laleau pour m’avoir proposé cette thèse en cotutelle. Son dy-namisme, ses encouragements et ses remarques constructives avec le recul nécessaire ont été des atouts notamment lors des phases de rédaction. Je remercie finalement ma dernière directrice de thèse, Amel Mammar pour son soutien continu qui s’est avéré inestimable, en particulier avec le début chaotique de ma vie de thésard. Sa disponibilité et sa réactivité ont été plus que bienvenues dans les périodes difficiles.
Ma thèse n’aurait pas été possible sans le soutien du Centre Hospitalier de l’Uni-versité de Sherbrooke qui a financé en partie ma thèse et fourni un sujet très intéres-sant avec une problématique concrète.
Je souhaite remercier tous les membres du GRIL au Québec, au sein duquel j’ai passé plusieurs années (maîtrise comprise), pour l’ambiance de travail idéale, en par-ticulier Raphaël, pour toutes les riches discussions que nous avons eues sur des sujets divers et variés. Je n’oublie pas les membres du LACL en France qui m’ont accueilli chaleureusement et avec qui j’ai partagé de nombreux repas, cours, TDs, TPs, et j’ai une pensée particulière pour les membres de mon bureau, Yohan, Quentin, Thomas, Assal et Rodica.
Je n’oublie pas mes proches, mes amis, ma famille pour tout le soutien moral, les relectures et tant d’autres choses...
ANSI American National Standards Institute
CHUS Centre Hospitalier de l’Université Sherbrooke
CSP Communicating Sequential Processes
DAG Directed Acyclic Graph
DPE Dossier Patient Électronique
DSD Dynamic Separation of Duty
EHR Electronic Health Record
NIST National Institute of Standard and Technology
OCL Object Constraint Language
OrBAC Organisation Based Access Control
PDAG Parametric Directed Acyclic Graph
RBAC Role Based Access Control
SGAC Solution de Gestion Automatisée du Consentement
SOD Separation Of Duties
SSD Static Separation of Duty
UML Unified Modeling Language
XACML eXtensible Access Control Markup Language
Sommaire v
Remerciements vii
Abréviations ix
Table des matières xi
Introduction 1
1 Validation de la norme ANSI à l’aide de B 9
1.1 Introduction . . . 12
1.2 Data structures of the ANSI RBAC standard. . . 14
1.2.1 Core RBAC . . . 15
1.2.2 Hierarchical RBAC . . . 19
1.2.3 Constrained RBAC . . . 23
1.2.4 Administrative functions . . . 25
1.3 The B specification of the RBAC standard . . . 33
1.3.1 CoreTools.mch . . . 34
1.3.2 Core.mch. . . 35
1.3.3 Hierarchical.mch . . . 35
1.3.4 Constrained.mch . . . 37
1.3.5 HierarchyConst.mch . . . 40
1.3.6 Proving acyclicity of the role hierarchy . . . 40
1.5 Related work . . . 46
1.6 Conclusion . . . 48
2 Formalisation de SGAC 51 2.1 Introduction . . . 55
2.2 Access Control Requirements at CHUS . . . 56
2.3 SGAC Data Structures, Rules and Requests . . . 58
2.3.1 Notation . . . 59
2.3.2 Using graphs . . . 60
2.3.3 Rule and request specification . . . 61
2.3.4 Conflict resolution . . . 63
2.4 Examples . . . 64
2.4.1 Example 1 : basics . . . 64
2.4.2 Example 2 : let’s get started . . . 65
2.4.3 Example 3 : adding consent . . . 67
2.5 Formal model . . . 69 2.5.1 Subject graph . . . 69 2.5.2 Resource Graph . . . 69 2.5.3 Rule . . . 70 2.5.4 Request . . . 72 2.5.5 Request evaluation . . . 72 2.5.6 Example . . . 76
2.5.7 Potential danger detection . . . 78
2.6 Related Work . . . 79
2.7 Performance comparison . . . 82
2.8 Conclusion . . . 83
3 Vérification de propriétés SGAC en Alloy et B 85 3.1 Introduction . . . 88
3.2 SGAC : presentation . . . 90
3.2.1 Rule and request specification . . . 90
3.2.2 Subject graph and resource graph . . . 90
3.2.4 Example . . . 93
3.3 Formalisation of SGAC . . . 93
3.3.1 Alloy . . . 93
3.3.2 SGAC in Alloy . . . 97
3.3.3 The B-Method and the ProB tool . . . 101
3.3.4 Formalisation in B . . . 105
3.4 Properties verification . . . 110
3.4.1 Accessibility . . . 110
3.4.2 Availability and contextuality . . . 112
3.4.3 Rule effectivity . . . 116
3.5 Performance tests . . . 119
3.5.1 Varying the number of contexts . . . 119
3.5.2 Varying the number of vertices . . . 120
3.5.3 Varying the number of rules . . . 120
3.5.4 Varying the number of possible requests . . . 120
3.5.5 Upper bounds . . . 121
3.6 Related work . . . 121
3.7 Conclusion . . . 123
Contexte et problématique
L’avènement de la dématérialisation des données, illustré par la prolifération des bases de données, facilite et accélère la circulation des informations. Dans cette op-tique, plusieurs pays ont décidé de mettre en place des structures de partage de données cliniques : les dossiers médicaux électroniques. Selon Inforoute Santé du Ca-nada [24], organisme mandaté par le gouvernement canadien pour la mise en place des dossiers médicaux électroniques, ces derniers permettent aux équipes de soins d’avoir une image plus complète de la santé de leurs patients et d’améliorer la communication entre les équipes soignantes.
On retrouve parmi les avantages octroyés par l’usage des dossiers médicaux élec-troniques :
— une efficacité accrue dans les cabinets de médecins avec des démarches plus simples et moins longues pour l’accès aux données patient. Par conséquent, les médecins se concentrent davantage sur les soins à prodiguer aux patients ; — une réduction des examens redondants, car les praticiens ont une vue précise
des examens déjà effectués ;
— une sécurité du patient accrue, grâce à l’historique des réactions aux différents médicaments ;
— une communication plus efficace entre les différents acteurs de la santé ;
— une meilleure prise en charge des patients pour les soins préventifs et la gestion des maladies chroniques.
Cependant, les modalités d’accès au dossier diffèrent selon chaque pays, voire province. Certains incluent par défaut le consentement du patient, c’est-à-dire que ce dernier doit se manifester s’il ne veut pas que ses données soient partagées sans son accord préalable. C’est le cas par exemple du Québec [13], de l’Alberta [36], du Royaume-uni. D’autres pays (e.g. France [9], Suède [35], Washington [49]) n’incluent pas le consentement du patient par défaut, le patient devant se manifester s’il veut que ses données soient partagées entre les différents établissements.
Dans le domaine médical, le secret professionnel et l’éthique du personnel soignant garantissent la confidentialité des informations renseignées sur des supports papiers. Au Québec, l’accès aux dossiers médicaux papiers se fait sous la supervision des archivistes qui gèrent les accès allant de la simple consultation au cas d’urgence, en passant par les cas de transfert de patients entre deux établissements. Cependant, avec le passage progressif au format électronique, la question de la gestion de l’accès aux informations dématérialisées se pose.
Les solutions adoptées par certains pays permettent au personnel soignant d’ac-céder soit à l’intégralité du dossier, soit à un sous-ensemble prédéfini en fonction du rôle de l’intervenant. Ce choix, loin d’être satisfaisant, ne permet pas au patient d’ex-primer son consentement d’une manière granulaire. En effet, accepter que ses données soient échangées équivaut à consentir aux accès de tous les intervenants : le patient ne peut permettre/interdire une personne en particulier d’accéder à une ressource en particulier.
Outre la nécessité de protéger le patient des fuites d’informations et des accès non autorisés, le contrôle d’accès doit prendre également en compte la sécurité physique du patient : en cas de restriction d’accès trop forte, le contrôle d’accès pourrait com-promettre la santé du patient en empêchant le personnel médical de prodiguer les soins adéquats par manque d’information.
Afin de laisser le patient gérer de lui-même la divulgation de ses données tout en garantissant sa sécurité, le Québec a choisi comme solution le consentement encadré par la loi. En effet, le consentement du patient est requis pour accéder à son dossier, à l’exception de cadres spécifiques définis strictement par la loi. Par exemple, lors d’une situation de vie ou de mort, les accès nécessaires à la prise en charge du patient dans ce contexte sont autorisés sans le consentement de celui-ci.
L’introduction du consentement permet au patient d’interdire des accès normale-ment autorisés par les règles de contrôle d’accès en vigueur, ou égalenormale-ment d’autoriser des accès qui auraient été interdits : un patient peut autoriser une sage-femme exté-rieure qu’il connaît personnellement à accéder à ses données psychiatriques même si cela n’aurait pas été en temps normal autorisé, à cause du profil de l’intervenant.
Cependant, la possibilité donnée au patient de spécifier lui-même des règles d’accès via son consentement introduit les problèmes potentiels suivants.
1. Des conflits peuvent survenir entre les règles définies par le patient et celles provenant des deux autres sources que sont le règlement interne de l’hôpital et la législation en vigueur. Ce problème est traité au cas par cas par les archi-vistes. Cela est possible pour l’instant vu le faible nombre de patients exprimant leur consentement en dehors du consentement global. Dans l’optique d’une uti-lisation du consentement à plus grande échelle, une solution systématique de résolution de conflits semble nécessaire.
2. Le patient peut provoquer une diminution drastique de la qualité des soins
reçus en interdisant au personnel soignant l’accès aux informations pertinentes.
Ce problème peut survenir lorsque le patient tente de masquer des données importantes telles que des allergies médicamenteuses ou des antécédents. Afin d’assurer la sécurité du patient et le sensibiliser aux choix qu’il fait, une situation où le patient cache des données jugées importantes doit pouvoir être détectée et il doit pouvoir être averti des conséquences du masquage.
3. Le patient peut faire des erreurs en ajoutant ses règles : il peut par exemple penser qu’en cas de conflit la dernière règle ajoutée l’emporterait. Dans ces cas, il est nécessaire de pouvoir montrer au patient les répercussions des nouvelles règles ajoutées afin qu’il puisse comparer ce qu’il attendait de ces règles et le comportement effectif.
4. Le patient peut accumuler des règles au fur et à mesure et ne plus s’y retrouver. Ce problème intervient lorsque le patient n’entretient pas sa base de règles et, par exemple, modifie sans supprimer ses règles. Afin d’assurer un fonctionne-ment optimal et une lisibilité dans la base de règles du patient, il est nécessaire de pouvoir faire le tri dans les règles et différencier les règles qui sont inutiles,
redondantes et donc supprimables.
5. Un patient peut produire un nombre important de règles, et avoir beaucoup de documents dans son dossier. Le système de gestion de contrôle d’accès doit pouvoir supporter un volume de données très important, de l’ordre de plusieurs centaines de milliers de patients et données.
La vérification et la validation des règles d’accès et des propriétés les concernant deviennent donc primordiales afin d’assister au mieux le patient dans la mise en place de ses règles et que celles-ci n’induisent pas de risques pour sa vie en dégradant la qualité des soins prodigués par le personnel. De plus, la vérification doit pouvoir prendre en compte le volume important de données.
Objectifs
Durant nos travaux de maîtrise [21], une étude comparative des différents moyens de gestion du consentement dans les échanges de données médicales a été effectuée. Avec l’aide de différents scénarios fournis par le Centre Hospitalier de l’Université de Sherbrooke (CHUS), nous avons mis au point une méthode de gestion de consente-ment, SGAC (Solution de Gestion Automatisée du Consentement). Elle permet de prendre en compte le consentement du patient, les règles usuelles d’accès des inter-venants des établissements de soins et ainsi que des règles issues de la législation en vigueur. La méthode de résolution de conflits qui surviennent entre les différentes règles, élaborée à la maîtrise, n’est pas parfaite, ni correctement définie et ne prend pas en compte tous les cas de figure. Cette thèse poursuit les travaux sur SGAC en le perfectionnant, notamment par l’ajout de méthodes de vérification appliquées aux politiques de contrôle d’accès aux données des patients. L’objectif, à terme, est d’élaborer un outil assurant au patient que le contrôle d’accès qu’il a mis en place est conforme à ce qu’il souhaite, et également cet outil doit être capable de l’avertir si les règles qu’il a définies risquent de dégrader la qualité des soins. Cet outil doit donc pouvoir simuler le comportement d’un ensemble de règles d’accès, résoudre les conflits entre celles-ci s’il y a lieu et détecter les cas d’informations inaccessibles.
— formaliser SGAC, décrire formellement le comportement de SGAC et notam-ment la méthode de résolution de conflits ;
— définir une méthode de détection de documents inaccessibles ; — définir une méthode de détection de règles inefficaces ;
— développer un outil de vérification pour SGAC ;
— définir des méthodes d’optimisation afin d’améliorer le temps de traitement des requêtes par SGAC ainsi que le temps de la vérification.
Contribution et plan de thèse
Nous adoptons ici le format d’une thèse par articles, dans laquelle chacun des trois premiers chapitres correspond à un des articles rédigés au cours de la thèse.
1. Évaluation d’un modèle de contrôle d’accès normalisé
Après avoir identifié les besoins du Centre Hospitalier de l’Université de Sher-brooke (CHUS ) pour la mise en place du contrôle d’accès pour le dossier patient électronique, nous nous sommes intéressés aux modèles de contrôle d’accès existants et leurs formalisations, afin de déterminer s’ils pouvaient être utilisés pour répondre à notre problématique. Nous avons commencé par étudier l’adéquation de RBAC (Role Based Access Control) [46], un modèle de contrôle d’accès normalisé et largement utilisé, pour déterminer si ce modèle pourrait permettre la mise en place du contrôle d’accès pour le dossier patient électronique.
Cette étude a requis de tout d’abord formaliser RBAC en B [1] en suivant la norme
ANSI. La méthode B [1] est une méthode de spécification formelle qui permet de spé-cifier un système de son analyse jusqu’à son implémentation. Cette formalisation rigoureuse a révélé des problèmes au niveau de la norme allant des fautes typogra-phiques aux erreurs de logique. Une liste détaillée des lacunes détectées et la méthode appliquée pour les vérifier, ainsi que des propositions de solutions de corrections font l’objet de l’article présenté dans le premier chapitre.
2. Proposition d’un modèle de contrôle d’accès
Au-delà des défauts identifiés dans la partie précédente, RBAC s’est par ailleurs avéré incompatible avec les besoins définis par le CHUS, du fait de l’impossibilité de gérer de manière satisfaisante les interdictions et les sources multiples de règles. En effet, les interdictions ne peuvent être exprimées directement, mais seulement en altérant les règles de permissions déjà en place, ces règles étant parfois issues de sources différentes. Il en découle une perte d’information et l’impossibilité de modifier une règle applicable à plusieurs patients.
Dans le cadre du même travail d’analyse de l’existant, nous avons aussi évalué d’autres modèles connus tels que OrBAC [27] (Organisation-Based Access Control)et XACML [43] (eXtensible Access Control Markup Language) pour vérifier s’ils pou-vaient s’appliquer à notre problématique. OrBAC ne répond pas aux exigences du CHUS puisqu’il ne permet pas de résoudre les conflits automatiquement. Quant à XACML, il satisfait la plupart des critères du CHUS, mais il est difficile à mettre en œuvre car il nécessite d’ordonner les règles à la main. De plus, ses performances sont insuffisantes, en particulier quand le volume de règles est important.
Nous avons donc travaillé à l’élaboration d’un modèle formalisé de gestion du consentement : SGAC (Solution de Gestion Automatisée du Consentement). L’article présenté dans le chapitre 2 décrit le fonctionnement de ce modèle, sa formalisation mathématique, les méthodes de vérification de propriétés qui lui sont attachées ainsi qu’une comparaison de performance avec XACML. Cette dernière conclut à une nette supériorité de SGAC pour résoudre les conflits dans le cas du CHUS.
3. Comparaison de deux outils de vérification sur notre modèle
Le modèle mathématique de SGAC et les méthodes de vérification de propriétés associées décrites dans le second article ont été mis au point avec pour but de pouvoir être utilisés avec des outils de vérification automatisés. En effet, l’automatisation de la vérification permettra à terme de proposer au patient un outil capable de :
— l’aider à vérifier que les règles qu’il ajoute ont bien les effets escomptés, c’est-à-dire lui indiquer quelles sont les personnes qui auront accès à ses données et dans quels contextes spécifiques,
— simplifier la base des règles que le patient a conçu pour améliorer la lisibilité en détectant les règles qui n’affectent pas le comportement du système,
— le prévenir des dangers potentiels lors du masquage de données importantes, de la dégradation de la qualité des soins qu’il recevra.
L’article constituant le troisième chapitre présente une étude comparative de deux outils de vérification en logique du premier ordre : Alloy [25] et ProB [29], comme solutions d’implémentation de l’automatisation de la vérification des propriétés énon-cées précédemment. La démarche appliquée a consisté à spécifier SGAC en Alloy et en B, qui sont les langages de spécification respectifs de Alloy et ProB, et à procé-der ensuite à des tests de performances dans le but de déterminer comment évolue le temps de réponse des deux outils en fonction des divers paramètres tels que le nombre de règles, de patients, de documents et de contextes. Les résultats montrent que ProB possède de meilleures performances et qu’il peut analyser un plus grand nombre de règles, de patients et de documents. Les limites de ProB, à savoir des graphes avec 300 sommets, 160 règles et 100 contextes avec 200 requêtes en 15 minutes, permettent de valider l’utilisation de notre modèle dans le cadre réel : des techniques de réduction peuvent être utilisées pour réduire la taille des graphes et le nombre de règles. De surcroît, des optimisations peuvent être apportées au modèle en B, par exemple en programmant l’ordre dans laquelle sont résolues les contraintes du modèle.
4. Conclusion et perspectives
Le dernier chapitre clôt cette thèse en présentant notre conclusion ainsi que les perspectives.
État de l’art
L’état de l’art est réparti dans les chapitres 1, 2 et 3.
Dans le chapitre 1, nous nous intéressons tout d’abord au modèle RBAC et à sa formalisation. Pour cela, nous étudions la norme et des travaux concernant la formalisation de RBAC, et la détection d’erreurs dans les spécifications de la norme.
Dans les chapitre 2 et 3, nous faisons une revue des différents modèles de contrôle d’accès qui pourraient convenir à la gestion du consentement : RBAC, OrBAC,
XACML. Nous nous intéressons également à la vérification de propriétés faite avec la
Validation de la norme RBAC
ANSI 2012 à l’aide de B
Résumé
L’article présente une étude critique de la norme ANSI de RBAC, un modèle de contrôle d’accès basé sur les rôles. RBAC est un modèle très utilisé et a fait l’objet d’une norme ANSI qui a été revue en 2012. L’article relève des incohérences dans la tentative de formalisation de RBAC de la norme grâce à la méthode B, et suggère des solutions aux problèmes trouvés. Les problèmes trouvés vont des fautes de typographie aux défauts de cohérence en passant par des problèmes d’imprécision. Les incohérences de la normalisation ont été découverts grâce à des violations d’invariants.
Commentaires
Le travail a été fait dans le cadre d’une étude de l’adéquation de RBAC avec les besoins du Centre Hospitalier de l’Université de Sherbrooke (CHUS) : est-ce qu’un modèle de contrôle d’accès déjà existant pourrait satisfaire les besoins du CHUS ? Les modèles les plus utilisés ont donc été analysés, dont l’un des plus connus et des plus répandus, RBAC. RBAC ne répond pas à première vue aux exigences du CHUS, car il est par exemple impossible de spécifier des interdic-tions, mais a la chance d’être doté d’une norme introduisant une formalisation du
modèle. Cette norme présente toutefois des erreurs qui ont d’abord attiré notre attention, puis motivé une étude approfondie, étude qui a permis de mettre en évidence des erreurs beaucoup plus sévères et de graves lacunes dans la norme et sa pseudo-formalisation.
Cet article a été accepté à la conférence ABZ 2014 qui a eu lieu à Toulouse, puis sélectionné et publié dans le journal Science of Computer Programming, pour l’édition spéciale consacrée à la conférence ABZ, en version longue qui est présentée ci-après. Ma contribution se résume comme suit :
— formalisation de RBAC en B en suivant à la lettre la description donnée dans la norme ;
— vérification du modèle à l’aide de preuves et d’outils tels qu’AtelierB et ProB ;
Nghi Huynh
Université de Sherbrooke, Québec, Canada Université Paris Est-Créteil, Val de Marne, France
Marc Frappier
Université de Sherbrooke, Québec, Canada
Amel Mammar
SAMOVAR, Télécom SudParis, CNRS, Université Paris-Saclay, EVRY, France
Régine Laleau
Université Paris Est-Créteil, Val de Marne, France
Jules Desharnais
Université Laval, Québec, Canada
Keywords: Role-Based Access Control; B method; invariant preservation
Abstract
We validate the RBAC ANSI 2012 standard using the B method. Numerous problems are identified: logical errors, inconsistencies, ambiguities, typing errors, missing preconditions, invariant violation, inappropriate specification notation. A clean version of the standard written in the B notation is proposed. We argue that the ad hoc mathematical notation used in the standard is inappropriate and we propose that a more methodological and tool-supported approach must definitely be used for writing standards, in order to avoid the issues identified in the paper. Human reviewing is insufficient to produce error-free international standards.
1.1
Introduction
RBAC is one of the most cited access-control models in the scientific literature (27 300 references in Google Scholar, 1 326 references in ACM digital library), and one of the most widely used models in industry [37]. It is an ANSI standard developed by INCITS (International Committee for Information Technology Standards) [2, 3, 46], with a first edition produced in 2004 and a recent revision published in 2012. It is recommended by numerous governmental agencies, like Canada’s Health Infoway, for controlling access to sensitive information like electronic health records (EHR). In a recent project on access control and consent management, we decided to follow these recommendations and evaluate the adequacy of RBAC for managing access to EHR. We were surprised by the number of errors and inconsistencies found in the standard. Even more surprising, all errors can be found in both editions (2004 and 2012), and the 2012 edition has been reviewed/voted by more than 141 persons (as listed in the standard).
The standard is written using mathematical definitions in the style of Z, but without strictly following the Z syntax. The mathematical definitions have not been syntax-checked nor type-checked, thus several errors could have been easily avoided. Some mathematical notations are not drawn from Z and seem rather ad hoc, as they are not easily found in standard mathematical textbooks, leaving the reader to guess their meaning from the context. More importantly, not sticking to the Z syntax also leads to several ambiguities, since the mathematical text interpreted with the Z semantics does not always match the natural language description. In order to make sense of the mathematical definitions, the reader must assume declarations which have been omitted in the Z schemas, relying on the natural language text to make such inferences. This is contrary to good specification practice, where the mathematical text is the definitive description, since it offers more precision than natural language. The standard leaves out important concepts, which certainly do not help in reaching the objective stated in the introduction of the standard:
Development [of] this standard was initiated [. . . ] in recognition of a need among government and industry purchasers of information technology products for a consistent and uniform definition of role-based access
con-trol (RBAC) features. [. . . ] This lack of a widely accepted model resulted in uncertainty and confusion about RBAC’s utility and meaning. This standard seeks to resolve this situation [. . . ].
The idea of using mathematics to write the standard was certainly a good idea, as it significantly helped in describing abstract concepts, and allowed us to identify incon-sistencies, ambiguities and missing elements. Finding errors in a natural language text is definitely more difficult, because too many interpretations are possible, and each reader picks one, according to his personal experience, knowledge and context. For comparison, we have also evaluated the XACML standard [43] where mathematics are not used at all. We found that it is far more difficult to grasp the subtle concepts of XACML and to be reasonably sure that we could comply to it. Thus, using math-ematics is a great idea, but it is insufficient to achieve the highest level of confidence in the quality of a standard. In this paper, we hope to show that the use of a formal method, which has a formal syntax and a formal semantics, supported by tools like syntax checkers, type checkers, provers, model checkers and animators, can definitely help in producing a precise and unambiguous description of a standard. We have chosen to use the B method for its rich tool set. In addition, we believe that B has helped us in detecting errors that may not be easy to find with Z, mainly because B requires proving invariant preservation, whereas in Z, invariants are typically included in the state definition and in the definition of operations through the ∆State decora-tion, as it was implicitly done in the RBAC standard. Proving invariant preservation helps in finding missing preconditions in operations and in reviewing the behaviour of operations when proof obligations fail.
Li et al published a critique of the 2004 standard in [32]. They identified several technical problems and suggested improvements to the standard, which they formu-lated using plain mathematics [31]. The leading authors of the standard responded to this critique in [16], without really agreeing on any of the critique of [32] (even the typos and type errors identified by Li et al are still present in the 2012 version of the standard). The improvements suggested by Li et al in [31] do not simply correct the logical flaws, but also propose a different view of RBAC, where, among other things, the notion of session is not included in the core part of RBAC, and permis-sions are inherited when a role hierarchy is used. Noticing issues with the format of
the specification of [31], Power et al [41] provided a formal Z specification of its state space, leaving out the specification of administrative functions described in [3]. They also suggested normalisation functions for permission assignment, and formalised the three interpretations of role hierarchy suggested in [31].
In this paper, our objective is to show that formal methods can significantly help avoiding errors in the specification of RBAC. We take the RBAC standard as it is described in [3], and fix all errors that we have found, to the best of our understanding of the natural language description and the accompanying mathematical text found in [3]. We do not suggest any new behaviour or feature, contrary to [31,41]. Another goal is to stress that formal methods should be used in a comprehensive manner when writing a standard. This includes specifying both the state invariant and the adminis-trative functions since specifying only the state invariant is insufficient. Proving that administrative functions preserve the invariant provides a greater level of confidence in the standard. We have identified errors that neither [31] nor [41] identified. Using a specification animator is also crucial to validate a specification. It allows to uncover inappropriate behaviours which can not be detected by invariant preservation proofs. The paper is structured as follows. Section 1.2 provides relevant excerpts of the RBAC standard [3] on data structures and administrative functions to update the value of RBAC data structures. Errors and omissions are identified and discussed. We describe and outline the structure of our B specification in Section 1.3. The complete specification is available in [12]. Section 1.4 provides an overview of the formal validation process we have used and discusses the advantages of using a formal method like B. Section1.5compares our findings with similar work on validating and specifying the RBAC standard. We conclude this paper with an appraisal of our work in Section 1.6.
1.2
Data structures of the ANSI RBAC standard
The RBAC standard [3] is decomposed in three components.
1. Core RBAC is the main component and is required in any RBAC system. 2. Hierarchical RBAC introduces a role hierarchy which defines role inheritance.
3. Constrained RBAC introduces separation of duties (SOD) constraints.
A compliant RBAC system is made of the Core RBAC component plus any combi-nation of the other two.
1.2.1
Core RBAC
The main idea of RBAC is that permissions are assigned to roles and users are granted these permissions by being assigned to roles. The Core RBAC component includes the following sets: USERS , ROLES , OPS , OBS and SESSIONS , which respectively stand for the set of users, the set of roles, the set of operations, the set of objects on which are applied the operations and the set of sessions where a user can activate a role.
The following definitions are reproduced verbatim from [3]. As a convention, all verbatim excerpts from [3] are in blue, while problems are inred within the excerpts and numbered in superscript. Problems are explained in the text following the ex-cerpts, numbered with Pi.
Core RBAC Reference Model
• USERS , ROLES , OPS and OBS1 (users, roles, operations and objects re-spectively).
• UA ⊆ USERS × ROLES , amany-to-many mapping2 user-to-role assignment relation.
• assigned users : (r : ROLES ) → 2USERS the mapping of role r onto a set of users.
Formally: assigned users(r) = {u ∈ USERS |(u, r) ∈ UA} • PRMS = 2(OPS×OBS)3, the set of permissions.
• PA ⊆ PERMS4× ROLES a many-to-many mapping permission-to-role as-signment relation.
• assigned permissions(r : ROLES ) → 2PRMS , the mapping of role r onto a set of permissions.
• Op(p : PRMS ) → {op ⊆ OPS }5, the permission to operation mapping, which gives the set of operations associated with permission p.
• Ob(p : PRMS ) → {ob ⊆ OBS }6, the permission to object mapping, which gives the set of objects associated with permission p.
• SESSIONS = the set of sessions.
• session users7(s : SESSIONS ) → USERS , the mapping of session s onto the corresponding user.
• session roles(s : SESSIONS ) → 2ROLES , the mapping of session s onto a set of roles.
Formally: session roles(si) ⊆ {r ∈ ROLES |(session users(si), r) ∈ UA}
• avail session perm8(s) → 2PRMS , the permissions available to a user in a session = S
r∈session roles(s)
assigned permissions(r)
Description of problems
P1Typo: all functions of Section 7 (Functional Specification Overview) of [3] use set OBJ S instead of OBS . OBS is declared here and used everywhere in this section, but not in the rest of the standard.
P2Improper terminology: in standard mathematics, a mapping is a function. The notion of a “many-to-many mapping” does not make sense strictly speaking. The term “relation” used further in the sentence suffices.
P3Type error: functions of Section 7 (Functional Specification Overview) of [3] use this set as if it was defined as OPS × OBS . Note that this set is never updated in any administrative functions of Section 7. This leads us to conclude that PRMS is a type and that all operations on objects are possible, that is, the standard does not provide means for controlling which operations are valid on which objects. On the other hand, functions Op and Ob, declared afterwards, but undefined, hint at the usage of a subset of operations on objects; otherwise, they would be
useless. But these functions are not used in the rest of the standard.
P4Typo: this symbol is not declared so far. One could presume that it is a typo for PRMS defined above and used everywhere in the rest of the data structure declarations, but PRMS is not used in Section 7; PERMS is used instead.
P5Unused symbol: this function is not used in the rest of the specification. By its description, it is a derived function, but its definition is not provided; only its type. Moreover, the notation {op ⊆ OPS } is not standard mathematics nor standard Z notation. One first guesses that its intended meaning is {op | op ⊆ OPS }, but since this sentence seems to be only providing a type for function Op, the set
OPS would suffice.
P6Unused symbol: same issues as for Op. This function is undefined and not used in the rest of the specification.
P7Unused symbol: this function is not used in the rest of the standard. The func-tion user sessions, which maps users to sessions is used instead (and undeclared anywhere).
P8Unused symbol: this function is not used in the rest of the standard. Administra-tive function CheckAccess provides the same information.
Appraisal of the definitions
Four symbols out of twelve are introduced upfront in the standard, but never used in the sequel. This generates unnecessary noise for the reader. Moreover, none of these definitions clearly emphasises under what conditions a user can use an operation on an object. This is quite surprising, because this is the core purpose of the standard. The definition of avail session perm describes the permissions available in a session, but it does not explicitly state that it determines if a user can execute an operation on an object. The reader has to wait until Section 7, page 17, where function CheckAccess,
buried among other administrative functions, nails it down in a decisive manner:
This function returns a Boolean value meaning whether the subject of a given session is allowed or not to perform a given operation on a given object.
The standard introduces a number of symbols (sets, relations, functions), but does not state whether they are state variables, specification parameters, or sets used only for typing. For instance, no distinction is made on the nature of sets USERS ,
ROLES , OPS and OBS . The first two are state variables (since they are updated by
some administrative functions of Section 7); the last two are never updated and can be considered as parameters of the specification used for typing only. These distinctions would be made if a formal specification like B, Z or ASM was used. The use of derived functions like assigned users, assigned permissions and avail session perms can cre-ate some confusion and inconsistencies when writing administrative functions. For instance, UA and assigned users(r) are both updated and kept consistent in admin-istrative functions updating them. Similarly for PA and assigned users. On the other hand, function avail session perm is never maintained in the administrative func-tions. Following common practice in the B method, these derived functions would not be included as state variables, since they do not contain any new information. Their inclusion would only complicate the invariant preservation proof and the specification of operations. They would be included as DEFINITIONS, which are similar to LET constructs in programming languages. Li et al. [32] also suggested not to use derived functions.
Finally, ad hoc mathematical notations are used (e.g., declaration of function Op), while in Section 7, the Z notation is said to be used for specifying operations. For the sake of uniformity, the Z notation could have also been used to define functions.
1.2.2
Hierarchical RBAC
This component introduces role hierarchies which define an inheritance relation among roles.
This relation has been described in terms of permissions: r1 “inherits" role r2 if9
all privileges of r2 are also privileges of r1. [...]
This standard recognizes two types of role hierarchies—general role hierarchies and limited role hierarchies. General role hierarchies provide support for an arbitrary partial order to serve as the role hierarchy, to include the concept of multiple inher-itances of permissions and user membership among roles. Limited role hierarchies impose restrictions resulting in a simpler tree structure (i.e., a role may have one or more immediate ascendants, but is restricted to a single immediate descendent).
General role hierarchy specification
• RH ⊆ ROLES × ROLES is a partial order on ROLES called the inher-itance relation written as , where r1 r2 only if10 all permissions of r2 are also permissions of r1, and all users of r1 are also users of r2, i.e. , r1 r2 ⇒ authorized permissions(r2) ⊆ authorized permissions(r1).
• authorized users(r : Roles) → 2USERS , the mapping of role r onto a set of users in the presence of a role hierarchy. Formally:
authorized users(r) ={u ∈ USERS |r0 r, (u, r0) ∈ UA}11
• authorized permissions12(r : ROLES ) → 2PRMS , the mapping of role r onto a set of permissions in the presence of a role hierarchy. Formally: authorized permissions(r) = {p ∈ PRMS |r0 r13, (p, r0) ∈ PA}
[. . . ]
Roles in a limited role hierarchy are restricted to a single immediate descendent. [. . . ]
Node r1 is represented as an immediatedescendent14 of r2 by r1 r2, if r1 r2
but no role in the role hierarchy lies between r1 and r2. That is, there exists no
Limited Role Hierarchy Specification
General Role Hierarchies16 with the following limitation: • ∀ r, r1, r2 ∈ ROLES ,r r1 ∧ r r217⇒ r1 = r2 .
Description of problems
P9Bad definition: this is the first sentence where the inheritance relation is described, and the standard uses a sufficient condition (“all privileges of r2 are also privileges of r1” ) to describe it; the reader shall later understand that this is instead a
necessary condition (i.e., a consequence of stating r1 r2).
P10Bad definition: this is the formal declaration of the inheritance relation, but it is provided in a necessary condition referring to two functions not declared yet (authorized users and authorized permission), leading the reader to question whether he has overlooked some definitions involving in the previous sections. Moreover, part of the sentence is reformulated in mathematics (authorized
per-mission), but the other part is not (authorized users), so the reader is not sure
if the mathematics covers one or both.
P11Formal definition: it should be {u ∈ U SERS| ∃ r0 • r0 r, (u, r0) ∈ UA}
in-stead, otherwise r0 would be a free variable. Same goes for the expression of authorized permissions.
P12Unused symbol: this function is never used in the rest of the standard. More-over, it leads the reader to believe that the permissions of a role include the permissions inherited by the role, but this is not the case. The reader shall later learn, after reading the definition of CheckAccess page 17 and CreateSession and AddActiveRole page 21, that a user only gets the permissions of his active roles, and the inheritance hierarchy has no effect on the permissions of a role. The inheritance hierarchy only determines the users authorised to activate a role. For instance, following the definition of the two aforementioned administrative func-tions, if r1 r2 and u 7→ r1 ∈ UA, then user u is allowed to activate r1 and r2. By
activating r1, user u only gets the permission granted to r1 in PA; the permissions
of r2can be exercised only if u also activates r2. Li et al. [32] claim that inheritance
as presented in the standard can be interpreted in three different ways, but we do not agree with them. If the reader sticks to the mathematical definitions of the standard, then there is only one plausible interpretation. Of course, the natural language text, the errors and superfluous definitions like authorized permissions create confusion, diverting the reader from the mathematical text, which should prevail. This shows the importance of properly distinguishing between definitions and propositions.
P13Error: it should be r r0, to match the necessary condition defined for just above, i.e.,
r1 r2 ⇒ authorized permissions(r2) ⊆ authorized permissions(r1)
This error was also pointed out by Li et al. [32].
P14Ambiguity: The sentence
Roles in a limited role hierarchy are restricted to a single immediate descendent.
and its formal representation as the following assertion
∀ r, r1, r2 ∈ ROLES , r r1 ∧ r r2 ⇒ r1 = r2
(where we have corrected the errorP17on explained below) entail that r2is the
descendent in r1 r2. This usage is also consistent with the formal definition
AddInheritance(r asc, r desc)
This commands establishes a new immediate inheritance relationship r asc r desc between existing roles r asc, r desc.
However, the following sentence defines r1 as the descendent:
Node r1 is represented as an immediate descendent of r2 by r1 r2, if r1 r2
but no role in the role hierarchy lies between r1 and r2.
Thus, there is confusion in the usage of the word “descendent”. This confusion probably arises from two different meanings of the word “descendent”. In the first case, it means “descending in power”, whereas in the second case, it means “descendent” in an inheritance hierarchy.
P15Error: the standard claims to define the covering relation of an ordered set, which they call immediate descendent, and which is typically used in Hasse diagrams. A third condition is missing to do so, namely r1 6= r3. This error was also pointed
out by Li et al. [32], but their suggested correction is incorrect: they suggest to replace r1 6= r2 by r1 6= r3, which is insufficient, because the intent of the
authors is to define the covering relation of a partial order. All three inequalities are required.
P16Version change: we have reproduced the 2004 version of the standard [2] here, because the 2012 version [3] uses Definition 2a instead, but there is no definition labelled with 2a in the standard.
P17Error: the standard claims to define the notion of single immediate descendent in a partial order, i.e., the partial order is a tree, as claimed in the following sentence:
Limited role hierarchies impose restrictions resulting in a simpler tree structure (i.e., a role may have one or more immediate ascendants, but is restricted to a single immediate descendent).
To do so, the standard should use instead r r1 ∧ r r2. This error was
also pointed out by Li et al. [32].
Appraisal of the definitions
Given all these problems, this section of the standard is quite hard to understand. The meaning of relation is unclear until the specification of the administrative functions is provided in Section 7 of the standard. This is where the reader learns the indirect effect of on the CheckAccess predicate, which describes if a user can perform an operation on an object in a given state of the RBAC system. Describing the connection between and the active sessions would help clarify the meaning of . The following assertion, which is the body of function CheckAccess, would show that does not directly impact the access a user has in a given state.
CheckAccess(s, op, ob) ⇔ s ∈ SESSIONS ∧ op ∈ OPS ∧ ob ∈ OBJ S ∧
∃ r • r ∈ ROLES ∧ r ∈ session roles(s) ∧ (op 7→ ob) 7→ r ∈ PA
This assertion shows that what is accessible is determined by the roles activated by a user in a session. One then has to find out how variable session roles is updated, by looking at the administrative functions updating it. This is where comes into play. Function AddActiveRole(u, s, r) says that user u can activate role r in session s if
u ∈ authorized users(r).
1.2.3
Constrained RBAC
Constrained RBAC adds Separation of Duty relations to the core RBAC model.
Static Separation of Duty is specified by a role set rs and an integer n such that
most (n − 1) roles of rs. Formally, let SSD be the set of the static separation of duty constraints : • SSD ⊆ 2ROLES × N • ∀(rs, n) ∈ SSD, ∀ t ⊆ rs : |t| ≥ n ⇒ \ r∈t assigned users(r) = ∅ • In presence of role hierarchy
∀(rs, n) ∈ SSD, ∀ t ⊆ rs : |t| ≥ n ⇒ \ r∈t
authorized users(r) = ∅
Dynamic Separation of Duty is specified by a role set rs and an integer n such that
2 ≤ n ≤ card(rs). That type of constraint specifies that a user can simultaneously hold at most (n − 1) roles of rs, during one session. Formally, let DSD be the set of dynamic separation of duty constraints :
• DSD ⊆ 2ROLES × N
• ∀ rs ∈ 2ROLES , n ∈ N, (rs, n) ∈ DSD ⇒ n ≥ 2, |rs| ≥ n and ∀ s ∈ SESSIONS , ∀ rs ∈ 2ROLES , ∀ role2subset ∈ 2ROLES , ∀ n ∈ N, (rs, n) ∈ DSD, role2subset ⊆ rs,
role2subset ⊆ session roles(s) ⇒ |role2subset| < n.
We did not find any problem with this part of the specification. However, these constraints could be expressed in a simpler manner, which we have done in our B specification [12].
1.2.4
Administrative functions
Administrative functions describe how the RBAC system state evolves. The stan-dard claims to use the Z notation for specifying administrative functions.
The notation used in the formal specification of the RBAC functions is a subset of the Z notation. The only change is the representation of a schema as follows: Schema-Name (Declaration) Predicate; . . . ; Predicate
Most abstract data types and functions used in the formal specification are defined in Section 3, RBAC Reference Model. New abstract data types and functions are introduced as needed.
Some examples of such specifications are provided below to illustrate problems with the adapted Z notation used in the standard. They are provided in Figure 1.1, 1.2,
1.3 and 1.4. The specification uses the following B operators. — dom(r) = {x | ∃ y · x 7→ y ∈ r} is the domain of relation r; — ran(r) = {y | ∃ x · x 7→ y ∈ r} is the range of relation r; — id(s) = {x 7→ x | x ∈ s} is the identity relation on set s;
— s C r= {x 7→ y | x 7→ y ∈ r ∧ x ∈ s} is the domain restriction of relation r by∆ set s;
— r B s= {x 7→ y | x 7→ y ∈ r ∧ y ∈ s} is the range restriction of relation r by set∆
s;
— s −C r = {x 7→ y | x 7→ y ∈ r ∧ x 6∈ s} is the domain antirestriction of relation r∆ by set s;
— r −B s = {x 7→ y | x 7→ y ∈ r ∧ y 6∈ s} is the range antirestriction of relation r by∆ set s;
— r[s]=∆ ran(s C r) is the image set of set s by relation r;
— closure1(r)= r∆ + is the transitive closure of relation r;
— closure(r)= r∆ ∗ = r+∪id(s) is the reflexive-transitive closure of relation r defined
AddUser
This command creates a new RBAC user. [. . . ]
AddUser (user : NAME )18
user 6∈ USERS
USERS0 = USERS ∪{user}
user sessions190= user sessions ∪ {user 7→ ∅ }
AddUser (user) = PRE
user ∈ USERS ∧ user 6∈ Users
THEN
Users := Users ∪ {user}
END;
Figure 1.1 – AddUser administrative function specification and translation — op(~x) = PRE C THEN S1 k . . . k Sn END is the declaration of an operation
op with parameters ~x, precondition C and assignment statements S1, . . . , Sn
which are simultaneously executed (“k”).
Description of problems
P18Notation: the notation used in the standard omits important elements of a Z operation schema. First, it does not identify the state space of the operation. A typical Z operation schema will include a ∆State declaration, introducing unprimed and primed variables, to denote the before and after states, and their associated invariant. The predicate part should describe the relationship between unprimed and primed variables. Primed variables which are not subject to any condition are allowed to take any value. Obviously, this convention has not been followed in the standard, because we do not expect operation AddUser to let all other state variables take any value after execution. Thus, we must assume that the standard uses the convention that primed variables x0 which are not occurring in the operation specification are preserved with the equality x0 = x. However, this
DeleteUser
This command deletes an existing user from the RBAC database. [. . . ]
DeleteUser(user : NAME )
user ∈ USERS
[∀ s ∈ SESSIONS • s ∈ user sessions(user) ⇒ DeleteSession(s)20]
UA0 = UA − {r : Roles • user 7→ r}
assigned users0 = {r : Roles • r 7→ (assigned users(r) − {user})}
USERS’= USERS − {user}
DeleteUser (user) = PRE user ∈ USERS ∧ user ∈ Users THEN
Sessions := Sessions − User sessions[{user}]
||
User sessions := {user} −C User sessions
||
Session roles := User sessions[{user}] −C Session roles
||
UA := {user} −C UA
||
Users := Users − {user}
END;
DeleteSession(user,session)
This function deletes a given session with a given owner user. [. . . ]
DeleteSession (user,session : NAME)21 =
user ∈ USERS ; session ∈ SESSIONS ; session ∈ user sessions(user) user sessions0 = user sessions − {user 7→ user sessions(user)} ∪
{user 7→ user sessions(user) − {session}}
session roles0 = session roles − {session 7→ session roles(session)}
SESSIONS0 = SESSIONS − {session}
DeleteSession (user,sess) = PRE
user ∈ USERS ∧ user ∈ Users ∧ sess ∈ SESSIONS ∧ (user 7→ sess) ∈ User sessions
THEN
User sessions := User sessions − {user 7→ sess}
||
Sessions := Sessions − {sess}
||
Session roles := {sess} −C Session roles
END;
DeleteRole
This command deletes an existing role from the RBAC database. [. . . ]
DeleteRole (role : NAME)22 =
role ∈ ROLES
[ ∀ s ∈ SESSIONS • role ∈ session roles(s) ⇒ DeleteSession(s)]
UA0 = UA − {u : USERS • u 7→ role}
assigned users0 = assigned users − {role 7→ assigned users(role)}
PA0 = PA − {op : OPS , obj : OBJ • (op, obj) 7→ role}
assigned permissions0 = assigned permissions− {role 7→ assigned permissions(role)}
ROLES0 = ROLES − {role}
DeleteRole (role) = PRE
role ∈ ROLES ∧ role ∈ Roles
THEN
User sessions := User sessions −B dom(Session roles B { role })
||
Session roles := dom(Session roles B { role }) −C Session roles
||
Sessions := Sessions − dom(Session roles B { role })
||
UA := UA −B {role}
||
PA := PA −B {role}
||
Roles := Roles − {role}
END;
DeleteRoleRH(role) = PRE
role ∈ ROLES ∧ role ∈ Roles
THEN DeleteRole(role) || RH := {role} −C RH −B {role} END DeleteRoleHC (role) = PRE
role ∈ ROLES ∧ role ∈ Roles ∧
∀ ssd.(ssd ∈ Ssd =⇒ role 6∈ ssd) ∧ ∀ dsd.(dsd ∈ Dsd =⇒ role 6∈ dsd)
THEN
DeleteRoleRH(role) END;
Figure 1.5 – DeleteRole administrative function specification and translation (2/2)
convention has not been followed everywhere. For instance, symbol is used in operation AddInheritance where is updated, but is not. However since is supposed to be the covering relation of , we can’t assume the equality 0= , because it would break the invariant linking and . This may
suggest that the standard assumes that derived functions need not to be explicitly updated since their definition acts like a state invariant which is assumed to be maintained by operations, as it is the case in Z when ∆State is used. But the standard doesn’t follow this convention either. For instance, in operations maintaining variable UA, which maps users to roles, variable assigned users is also maintained, which is not needed, since assigned users is derived from UA.
P19Undeclared symbol: variable user sessions has not been declared in the data structures in the previous section. Variable session users, which has been de-clared in the data structure section, is not updated by this operation. So the assumption we made inP18to make sense of the notation used is broken here,
be-cause it makes session users inconsistent with user sessions. Luckily, session users does not seem to be used at all in the specification of administrative functions, so we deduce that its declaration is superfluous in the data structure section of the standard, which solves the inconsistency problem.
P20Notation: this is one example of operation call which does not follow the Z syn-tax and that is logically unsatisfiable. The reader must suppose that a more “imperative programming language” view is used here. There are other cases in the standard (e.g., AddAscendant, AddDescendant, where the two calls are represented implicitly as a conjunction, but sequential composition should have been used, to make sense out of it).
P21Signature inconsistency: DeleteSession is declared with parameters (user,
ses-sion: NAME), but called as DeleteSession(session) in DeleteRole and Dele-teUser. Since a session is related to a single user, as provided by the unused
function session users, there is no need for parameter user. Note also that updating function session users is simpler than updating its functional inverse
user sessions, i.e.,
session users0 = {session} −C session users .
The Z domain subtraction is not used in the standard, and that makes the spec-ification harder to read.
P22Operation DeleteRole does not update relation “” and separation of duty constraints SSD and DSD. The last two ones raise more serious issues to deal with. We see two options:
— remove the deleted role from all the constraint role sets where it appears; — restrict the operation to a role which is not used in SSD/DSD constraints. The first option raises the issue of updating the cardinality. Recall that an SS-D/DSD constraint (RS, n) states that at most n − 1 roles of RS can be assigned to/activated by a user. It is subject to the invariant n ≥ 2∧|RS| ≥ n. If |RS| < n,
then the constraint can never be violated and it is useless. After deleting a role, we have the following cases:
— n > 2∧|RS0| = n−1: n must be decremented by 1, in order for the constraint to satisfy the state invariant;
— if n = 2 ∧ |RS0| = 1, the constraint is deleted because it does not satisfy the state invariant |RS0| ≥ n and n cannot be fixed by decrementing n, since
n ≥ 2 is required by the state invariant;
— |RS0| ≥ n: n could be decremented by 1 or left unchanged; it depends on the particular access-control requirements of the application.
In any case, the constraint could be deleted if it does not make sense in the security requirements of the application. Furthermore, removing a role in a con-straint role set may introduce concon-straint redundancy: if two concon-straints have the same role set, the one with the bigger cardinality is redundant. Then,
Delete-Role should in addition remove the redundant constraint. Given these cases, it
seems safer to let the RBAC manager manually adjust SSD/DSD affected by a role deletion before deleting a role. Hence, we have added a precondition in our specification of DeleteRoleHC in Figure 1.4 to check that a role is not used in any SSD/DSD constraint.
We have discovered this issue by proving that operations preserve state invariants and it hasn’t been raised in [31, 41].
Appraisal of the definitions
There are two main issues in this section. The first one is the inappropriate usage of the Z notation, which leads to incorrect specifications of several operations that are logically unsatisfiable, but the intent of the specifiers is reasonably understandable. The second one raises a more serious problem; there are missing preconditions in operation DeleteRole which cause an invariant violation. We have proposed a new version of this operation in order to have a coherent set of SSD/DSD constraints when a role is deleted.
Figure 1.6 – Architecture of our B specification of the RBAC standard
1.3
The B specification of the RBAC standard
Due to space limitation, our B specification is partly omitted and fully provided in [12]. Our specification is structured as follows. Each RBAC component has its own machine, and the Core RBAC machine is included in the other two components. We have a total of five machines; their relationship is illustrated in Figure 1.6.
— CoreTools.mch: This is an auxiliary machine which contains the declaration of elements which are needed in each of the machines representing an RBAC ponent. Thus, it contains the common features needed by each RBAC com-ponent: abstract sets, state variables and operations representing the core be-haviour of administrative functions, with weakened preconditions to be reused and strengthened in the other machines according to their needs.
— Core.mch: This machine includes CoreTools.mch and represents Core RBAC. — Hierarchical.mch: This machine includes CoreTools.mch and introduces the
in-heritance relation among roles. It represents Hierarchical RBAC.
— Constrained.mch: This machine includesCoreTools.mchand introduces the static and dynamic constraints for separation of duty, by adding them to the invari-ants. It represents Constrained RBAC.
Component LOC Proof Obliga-tions W.D. PO Automatic Interactive CoreTools.mch 275 51 0 42 9 Core.mch 25 0 0 0 0 Hierarchical.mch 110 16 0 6 10 Constrained.mch 250 105 22 69 58 HierarchyConst.mch 295 112 25 69 68 Table 1.1 – Statistics on our RBAC model in B
— HierarchyConst.mch: This machine includesHierarchical.mchand adds constraints to represent separation of duty. It represents the combination of Hierarchical RBAC and Constrained RBAC.
Table 1.1 provides statistics on model size and proof obligations, including well-definedness proof obligations. Automatic proofs were automatically discharged by the prover; interactive proofs required human intervention to guide the prover in finding a proof. For information, it took around a hundred hours to fully read, understand, model the standard: most of the time spent have been used into proofs, debugging the specification and animation.
1.3.1
CoreTools.mch
Figure1.7a presents the static part of CoreTools.mch, which contains the declara-tion of the core sets, the core variables and the invariants. Choices have been made to simplify the model by removing the relation assigned user since it is derived from
UA. The same goes for assigned permission and PA. CoreTools.mch has all the fea-tures needed for Core RBAC except the fact that it does more than Core RBAC: it has auxiliary operations which are called by machines including CoreTools.mch. In B, a machine D which includes a machine C has read-only access to the variables and sets of C. To modify the variables of C, machine D must invoke C’s operations. Op-eration promotion lets the including machine claim the promoted opOp-eration from the included machine as its own. Proofs are also inherited: including a machine already proven reduces the number of proofs obligation to discharge in the including
