Résumé du projet POLITESS - ANR-05-RNRT-01301
Le projet POLITESS a
étudié des
méthodes pour s'assurer d'une bonne mise en oeuvre de politiques de
sécurité
pour des systèmes d'information en réseau par exemple ceux que
l'on peut bâtir
avec des compositions de services Web. De nombreuses pistes de
recherche ont
été poursuivies et ont apporté des éléments de solution. Toutes sont
basées sur
une modélisation formelle des exigences de sécurité.
SP1. Proposition de modèles
unifiés pour exprimer
différents aspects des
politiques de sécurité. Le projet POLITESS est parti du modèle OrBAC,
et l'a
étendu pour exprimer les politiques de contrôle d'accès dépendant de
contextes
dynamiques, le contrôle d'usage et le traitement des anomalies
(livrables
numérotés L1.x). Un modèle UML/OCL permettant de coupler les
spécifications de
sécurité aux spécifications fonctionnelles a aussi été défini (L1.6).
Pour les
règles isolées, des formules de logiques modales ont également été
utilisées
(logique Nomad et logique temporelle).
SP2. Pour garantir
des échanges
d'information entre domaines ayant des politiques propres (ce qui peut
être le
cas dans des architectures à base de services Web en particulier), on a
défini
un protocole de négociation de politiques. La négociation se fait
dynamiquement
lors des demandes d'accès (L2.1 et L2.3).
SP3. Le test de
conformité est
une approche générale pour valider la bonne mise en oeuvre des
spécifications
d'un système. Le projet POLITESS a proposé différentes approches et
développé
des prototypes correspondant à différents types de spécification, de
propriétés
de sécurité ou de contextes d'exécution. On a également étudié le test
de
propriétés génériques de sécurité, comme l'opacité (L3.3). Une méthode
de
découverte de canal caché a également été proposée (L3.7).
SP4. Après
déploiement d'une
politique, on peut vérifier le respect des règles par une observation
passive
des échanges d'information et des actions sur le système. Le projet
POLITESS a
proposé des techniques de construction de moniteurs analysant les
traces d'un
système. On a également étudié les conditions de détection de fuites
d'information confidentielles en se basant sur la théorie du diagnostic
sur les
systèmes à événements discrets.
SP5. Des études de
cas issues de
France Télécom et SAP ont pu servir de fil conducteur ou de base
d'expérimentation pour les prototypes. On a étudié ainsi une
application de
gestion des missions (Travel), et plusieurs applications de SAP, en
particulier
une application bancaire de gestion des autorisations de crédits.