Méthodes formelles pour la collecte et l`analyse de logs Projet LISE

1
Méthodes formelles pour la
collecte et l’analyse de logs
Projet LISE
ANR-07-SESU-007
Daniel Le Métayer
2
Partenaires du projet LISE
•
AMAZONES (INRIA Grenoble Rhône-Alpes, INSA de Lyon)
STIC
•
DANTE (Université de Versailles Saint-Quentin)
Droit
•
LICIT (INRIA Grenoble Rhône-Alpes)
STIC
•
PRINT (Université de Caen)
Droit
•
SSIR (SUPELEC, Rennes)
STIC
•
VERIMAG (Université de Grenoble)
STIC
3
LISE – Contexte
Constat:
•
Omniprésence des logiciels dans tous les domaines d’activité
•
Difficultés à définir les responsabilités en cas de dysfonctionnement:
• Juridiques: validité des clauses limitatives
• Techniques: caractérisation des dysfonctionnements
• Juridico-techniques: liens entre dysfonctionnements, dommages
et responsabilités des acteurs, qualité des éléments de preuves
4
LISE – Objectifs
Fournir un ensemble de méthodes et d’outils informatiques et juridiques
permettant aux parties
•
de définir précisément leurs responsabilités respectives pour
certains types de dysfonctionnements de systèmes logiciels
•
d’établir ces responsabilités après les faits en cas de
dysfonctionnement
5
LISE – Démarche
Démarche pragmatique:
•
•
Diversité des situations (techniques, économiques, juridiques) et des
intentions des parties ⇒
Ensemble de méthodes et d’outils utilisables en fonction des
besoins plutôt que cadre monolithique
Périmètre:
•
Cadre contractuel (ne s’applique pas à la criminalité informatique)
•
Responsabilités liées aux dysfonctionnement des logiciels
seulement (ne s’applique pas à la contrefaçon)
6
Exemples de questions pertinentes
1. Architecture de logs:
•
Quelles données faut-il inscrire dans des fichiers de logs ?
•
Où ces données doivent-elles être stockées (et par quels acteurs) ?
2. Analyse de logs:
•
Comment analyser ces fichiers logs a posteriori ?
•
Comment établir un lien entre les dysfonctionnements constatés et
les responsabilités?
7
Méthodes formelles et responsabilités
Intérêts des méthodes formelles dans le contexte des responsabilités:
• Définitions précises et non ambiguës des dysfonctionnements et
des responsabilités
• Base pour la réalisation d’outils:
– Conception et évaluation d’architectures de logs
– Analyse de logs
8
LISE
Définition formelle
des responsabilités
Contrat
Architecture de logs
Analyseur de logs
Responsabilités
9
Point de départ de la formalisation:
les griefs
Un grief est constitué de 3 parties:
1. Le plaignant: acteur X
2. Le défendeur: acteur Y
3. Le motif: propriété D sur les traces d’exécution du système
(dysfonctionnement)
Notation: G(X, Y, D)
Trace d’exécution: séquence d’événements
10
Exemple d’application:
service de réservation d’hôtels
Exemple de grief:
G(Dupont, Agence, D) avec
D(T) ≡ ∃ (Confirmation, Agence, Dupont, [Resa, Hotel, Date]) ∈ T ∧
⎤ ∃ (Reservation, Hotel, Dupont, [Resa, Date]) ) ∈ T
11
1
FORMALISATION DE
L’ARCHITECTURE DE LOGS
12
Formalisation d’une architectures de logs
Une architecture de logs associe à chaque type d’événements:
•
Les acteurs en charge d’inscrire les événements concernés dans
leur log
•
Les acteurs en charge de signer les événements concernés
NB: chacun de ces ensembles peut être vide pour un type d’événement
donné
13
Caractérisation d’une
architecture de logs acceptable
Une architecture de logs est acceptable si:
•
Tout type d’événement susceptible d’avoir une influence sur la
validité d’un grief est enregistré dans au moins un log et
•
Les acteurs en charge de les enregistrer dans leurs logs sont
neutres par rapport à ce type d’événements ou
•
Ces événements ne sont ni favorables aux acteurs en charge de les
signer ni défavorables aux acteurs chargés de les inscrire dans leurs
logs
14
Intérêts de la notion
d’acceptabilité
Formalisation de la notion d’acceptabilité:
•
Preuve de correction par rapport à un modèle de menaces:
l’évaluation de la validité des griefs à partir des logs est conforme à
une évaluation de cette validité par rapport aux événements réels
•
Critères d’analyse d’une architecture pour déterminer son
acceptabilité (et l’améliorer le cas échéant)
15
Exemple d’application
G(Dupont, Agence, D) avec
D(T) ≡ ∃ (Confirmation, Agence, Dupont, [Resa, Hotel, Date]) ∈ T ∧
⎤ ∃ (Reservation, Hotel, Dupont, [Resa, Date]) ) ∈ T
•
Une architecture de logs prévoyant seulement l’inscription des
événements (non signés) par l’émetteur et le destinataire n’est pas
acceptable
•
Deux solutions pour rendre l’architecture acceptable:
•
•
Evénements signés par Agence et enregistrés par Dupont
Evénements enregistrés par un tiers neutre par rapport à ce type d’événements
16
2
FORMALISATION
DE L’ANALYSE DE LOGS
17
Exemple d’application: solution de signature
électronique sur un téléphone mobile
•
Signataires du contrat:
•
•
•
MPP: fournisseur du téléphone et opérateur téléphonique
SAP: fournisseur de l’application de signature (App-Sig)
SCP: fournisseur de la carte à puce
•
Hypothèses:
•
Les parties souhaitent définir leurs responsabilités en cas de
dysfonctionnement du système installé sur le téléphone (téléphone,
carte et application App-Sig) ⇒
•
On ne considère pas les dysfonctionnements liés au serveur ou au
réseau de communication
18
Exemples de griefs considérées
Griefs relatifs à un document Doc opposé au client Dupont par le
marchand pour la transaction N :
•
•
Inexact: Dupont affirme que le document qui lui a été présenté pour
cette transaction était différent du document Doc
Nonsigne: Dupont affirme qu’aucun document correspondant à une
transaction N ne lui a été présenté
19
Exemple d’accord informel entre les parties
Si le client affirme que le document qui lui a été présenté pour la
transaction N était différent du document qui lui est opposé par le
marchand et que sa plainte est valide alors:
• SAP sera responsable si App-Sig a transmis à l’afficheur un
document différent du document reçu du serveur ou différent
de celui renvoyé au serveur (avec l’estampille N)
• Sinon MPP sera responsable
20
Modélisation formelle
Resp (D, T, N) =
Si D = Inexact ∧ Inexact (T,N)
Alors
Si Diff (T,N)
Alors SAP
Sinon MPP
Si le client affirme que le document qui lui a été présenté pour la transaction N
était différent du document qui lui est opposé par le marchand et que sa plainte
est valide alors:
• SAP sera responsable si App-Sig a transmis à l’afficheur un document
différent du document reçu du serveur ou différent de celui renvoyé au
serveur (avec l’estampille N)
• Sinon MPP sera responsable
21
Correspondance
Resp (D, T, N) =
Si D = Inexact ∧ Inexact (T,N)
Alors
Si Diff (T,N)
Alors SAP
Sinon MPP
Si le client affirme que le document qui lui a été présenté pour la transaction N
était différent du document qui lui est opposé par le marchand et que sa plainte
est valide alors:
• SAP sera responsable si App-Sig a transmis à l’afficheur un document
différent du document reçu du serveur ou différent de celui renvoyé au
serveur (avec l’estampille N)
• Sinon MPP sera responsable
22
Définitions plus souples de la responsabilité
Intérêts de cette formalisation :
•
•
•
Simplicité
Correspondance avec les caractérisations en langue naturelle
Fondement pour l’analyse de logs
Inconvénient:
Définition rigide
Généralisation:
Notion de causalité entre un ou des faits générateurs (erreurs) et un
dysfonctionnement
23
Définitions formelles de causalité
•
Difficulté:
•
•
•
Possibilité d’existence de plusieurs erreurs dans une trace ⇒
Nécessité d’identifier les erreurs qui sont véritablement à l’origine du
dysfonctionnement
Définitions formelles:
•
•
•
Causalité simple: existence de dépendance logique entre l’exécution erronée
d’un composant C et un dysfonctionnement
Causalité nécessaire: le dysfonctionnement ne se serait pas produit si le
composant C s’était exécuté sans erreur (indépendamment des comportements
des autres composants)
Causalité suffisante: l’exécution erronée du composant C devait inévitablement
provoquer le dysfonctionnement (indépendamment des comportements des
autres composants)
24
Bilan
•
•
•
•
Des critères formels pour
• Concevoir une bonne architecture de logs
• Définir précisément certaines attributions de responsabilité
• Analyser les logs de manière incrémentale
Des applications à des études de cas
Une architecture de logs en OSGi (Open Services Gateway initiative)
pour la signature électronique sur mobile
Possibilité d’utiliser ces principes, méthodes et outils de manière
pragmatique, en fonction des besoins.
25
Conclusion
•
•
Bénéfice: aide aux parties ou aux experts pour déterminer les
responsabilités de manière la plus objective possible
Philosophie : considérer la problématique des responsabilités
juridiques en amont, de façon à faciliter le règlement des
différends potentiels entre les parties le cas échéant
Après le “security by design”, le “privacy by design”,
l’”accountability by design” ?