Formalisation de propriétés de flux d information avec une logique temporelle du premier ordre pour assurer la sécurité d une infrastructure de Cloud

Dimension: px
Commencer à balayer dès la page:

Download "Formalisation de propriétés de flux d information avec une logique temporelle du premier ordre pour assurer la sécurité d une infrastructure de Cloud"

Transcription

1 Formalisation de propriétés de flux d information avec une logique temporelle du premier ordre pour assurer la sécurité d une infrastructure de Cloud Arnaud Lefray,, Jonathan Rouzaud-Cornabas Université de Lyon - Laboratoire LIP UMR CNRS - ENS de Lyon - INRIA - UCB Lyon 5668 INSA Centre Val de Loire - Université d Orléans, LIFO EA 4022, Bourges, France Résumé L adoption massive du Cloud est principalement freinée par le manque de sécurité. Le concept de sécurité à la demande consiste à proposer et appliquer les objectifs de sécurité du client. Dans ce papier, nous présentons une approche, nommée Information Flow Past Linear Time Logic (IF-PLTL), pour spécifier un large panel de propriétés de sécurité d un système. Nous présentons également comment contrôler les flux d information à partir d évènements de bas niveau. Nous décrivons en détail la syntaxe et la sémantique de IF-PLTL. De plus, cette logique permet de formaliser un large ensemble de politique de sécurité paramétrable par un client. Nous illustrons cette approche avec une politique d isolation basée sur des propriétés de non-interférence. Enfin, nous discutons l extension avec des ensembles dynamique de IF-PLTL pour inclure des cas d usage plus réalistes comme la politique d isolation dynamique des domaines. Mots-clés : Sécurité, Flux d information, Cloud, Système formel, Sémantique. 1. Introduction L adoption massive du modèle Cloud est principalement freinée par le manque de sécurité [16]. Un environnement de Cloud fait face à diverses menaces allant des attaques traditionnelles sur les systèmes d exploitation (SE) (au niveau hyperviseur ou machine virtuelle) ou les réseaux, jusqu aux nouvelles menaces issues des environnements partagés tels que les ressources matérielles partagées au niveau IaaS [5], les ressources (virtuelles) systèmes partagées au niveau PaaS [14], et les ressources applicatives partagées au niveau SaaS. Une politique de sécurité efficace doit prendre en compte tous les niveaux multi-tenants, à savoir, IaaS, PaaS et SaaS. Sécuriser les Clouds est un domaine de recherche très actif dont témoigne les nombreux projets académiques et industriels en cours. Nous pensons qu un concept clé est de délivrer une sécurité à la demande. Un utilisateur doit pouvoir spécifier quel est le comportement sécurisé de son système. Ainsi, nous devons proposer un langage qui permet l expression d objectifs de sécurité spécifiques à un client. Cependant, spécifier ou configurer une politique de sécurité est très souvent complexe et sujet à erreur. Même en tant qu expert de la sécurité, un humain peut toujours effectuer une mauvaise

2 configuration donnant lieu à des failles. Pour cette raison, les politiques de sécurité doivent être appliquées de manière automatique, c est-à-dire où l intervention humaine est réduite à sa stricte nécessité. Par exemple, le comportement souhaité d un système, c est-à-dire ce qu il doit ou ne doit pas faire, ne peut être spécifié que par le client. Par conséquent, après cette première étape de spécification, le système doit adopter un contrôle d accès obligatoire (Mandatory Access Control) où même l utilisateur ayant tous les privilèges (root) ne peut modifier la politique de sécurité. Halpern et al. [10] avancent que des politiques de sécurité décrites dans un langage naturel ont une sémantique ambigüe. En revanche, un langage formel (ou une logique) ont une syntaxe et une sémantique très claires. Dans ce papier, nous proposons une logique adéquate pour un système concurrent, nondéterministe et multi-tenant. Pour être utilisable en pratique, notre système formel doit satisfaire les contraintes suivantes : 1. Il doit modéliser la manière dont l information est échangée, à savoir des flux d information directs, transitifs ou intransitifs. 2. Il doit modéliser des systèmes multi-domaines, concurrents et non-déterministes. 3. Il doit être utilisable par des non logiciens tels qu un client IaaS. Lorsque qu ils sont correctement configurés, de nombreux mécanismes de sécurité ont prouvé leur efficacité pratique, par exemple SELinux ou Iptables. Considérant qu une sécurité ne doit pas dépendre d une technologie unique, la formalisation d objectifs de sécurité doit être suffisamment expressive pour être projetée vers la logique interne de ces mécanismes de sécurité. Le papier est organisé comme suit. La section 2 discute des trois contraintes et motive notre travail en examinant les approches de sécurité existantes. La section 3 décrit comment modéliser un système avec des traces de flux d information. La section 4 décrit la syntaxe et la sémantique de notre logique IF-PLTL. La section 5 illustre les propriétés de haut-niveau et étend IF-PLTL avec des annotations pour forcer la dynamicité des ensembles de contextes en montrant son intérêt avec une politique d isolation dynamique des domaines. Enfin, la section 6 conclut avec les perspectives et les questions ouvertes. 2. Motivations Le contrôle de flux d information (IFC) et le contrôle d accès peuvent être vus comme des approches différentes mais potentiellement complémentaires pour assurer la sécurité [11]. En effet, le contrôle d accès spécifie explicitement les permissions d un acteur vis à vis d une action sur une ressource tandis que les flux d informations (IF) sont implicites. Le contrôle de flux d information spécifie explicitement les flux autorisés tandis que les permissions pour réaliser une action particulière sont implicites. Une politique d IF entre deux entités est soit directe, transitive ou intransitive. Supposons une politique autorisant des flux directs d une entité A vers une autre B et également de B vers C. Une politique transitive autorisera un flux direct de A vers C par transitivité. Cependant une politique intransitive refusera un flux direct de A vers C mais permettra un flux de A vers C passant par B. Ces politiques d IF sont difficiles à exprimer [15] mais elles sont essentielles. C est pourquoi, nous devons les inclure dans notre formalisme. Les systèmes d IFC abordent tous types d environnements depuis les systèmes statiques jusqu aux moniteurs de référence (à l exécution). Dans le cas statique, les propriétés d IF sont vérifiées sur un modèle complet du système [8]. Dans le cas dynamique, les propriétés d IF sont

3 vérifiées à l exécution [7]. Dans notre approche, nous proposons un système formel incluant à la fois le cas statique et celui dynamique. A notre connaissance, les travaux les plus proches des nôtres ont été effectués par Basin et al. dans [2]. Leur approache est similaire à la nôtre dans le sens où elle inclut les modalités de temps de la logique temporelle linéaire passée (P-LTL) et elle modélise le comportement d un système avec des (ensembles de) traces. Néanmoins, leur proposition diffère de la nôtre en ne modélisant pas explicitement des flux d information et en définissant un ensemble de relations dépendant du cas d utilisation. Utiliser un IFC dans les Clouds pour assurer des objectifs de sécurité a été mis en avant [1, 16] mais jamais appliqué. L utilisabilité est également un facteur qui doit être pris en compte lorsque l on propose une nouvelle approche de sécurité. En effet, si la description d objectifs de sécurité est trop complexe, alors l approche ne peut être utilisée en pratique. C est pourquoi nous proposons une API de haut-niveau composée de politiques de sécurité généralistes, chaque propriété les composant étant définie formellement. La formalisation présentée dans ce papier est issue du langage PIGA mais revisitée avec plus de formalisme et de généralisation. Le langage PIGA a été utilisé pour implanter des moniteurs de référence dans divers environnements comme PIGA-OS, PIGA-Virt, PIGA-Cluster et PIGA- Dalvik [3, 4]. Aperçu de notre approche Dans cette section, nous avons discuté de la contrainte suivante Il doit modéliser la manière dont l information est échangée, à savoir des flux d information directs, transitifs ou intransitifs et défini le spectre de notre étude aux IFCs systèmes avec analyse statique et monitoring dynamique. La deuxième contrainte Il doit modéliser des systèmes multi-domaines, concurrents et nondéterministes a été motivée principalement par l architecture multi-tenante des Clouds. La dernière contrainte Il doit être utilisable par des non logiciens tels qu un client IaaS est plus intuitive et peut être achevée en proposant une API simple de haut-niveau. Notre objectif est de décider si le comportement d un système, modélisé par des traces, satisfait une politique de sécurité formalisée par des formules logiques. Une trace est une séquence de transitions d états. Un système ne produit par directement des flux d information mais des évènements observables de bas niveau. Ces évènements sont transformés en évènements fonctionnels et finalement en flux d information. Une trace d IF satisfait (ou non) une politique de sécurité, c està-dire un ensemble de formules closes appelé théorie. Enfin, une API adaptée à l utilisateur est proposée via un ensemble de propriétés de haut niveau paramétrables, l exemple de la politique d isolation dynamique des domaines étant donnée dans la section Modélisation d un système : les traces Dans cette section, nous présentons comment construire des traces d IF à partir d évènements de bas niveau. Pour définir la sécurité dans un Cloud IaaS composé de SEs virtuels et physiques, nous devons représenter un système concurrent et non-déterministe. Nous définissons un système primitif comme une boîte noire avec un état interne et une interface acceptant un ensemble d actions. Ainsi, un système est une composition (récursive) de systèmes primitifs (ou systèmes). Toutes entités d un environnement type SE, à savoir les fichiers, processus, bases de données, peuvent être vue comme des systèmes. Chaque machine virtuelle est également un sous-

4 système d un Cloud. Le comportement concurrent d un système peut être modélisé par les traces d exécution générées par ce système [12], où une trace d exécution est une séquence de transitions d états déclenchées par des évènements et vue par un observateur. Nous définissons cet observateur comme une entité passive avec une vue (potentiellement partielle) du système. Supposons un système avec seulement trois entités (a, b, c). a voit une trace partielle composée de tous les évènements partant de ou allant vers lui-même mais il ne peut pas voir les évènements entre b et c. De plus, un évènement de a vers b est à la fois inclus dans les traces de a et de b. Par conséquent, l union de toutes les traces partielles forme une trace complète du système. Les entités étant de types hétérogènes, elles sont identifiées par des contextes, c est-à-dire des références abstraites à des entités ayant un ensemble commun de caractéristiques. Nous supposons l existence d une méthode permettant d attribuer un contexte à toute entité, sachant que deux entités avec le même contexte ont un ensemble commun de caractérisques (comportement, domaine de sécurité, type, etc.). Par la suite, nous notons SC l ensemble de tous les contextes Traces avec évènements observables Le noyau a une vue complète de toutes les traces d un SE. Les appels noyaux, tels que sys_read, sys_write, sys_fork, impliquent une entité source et une entité destination (potentiellement nouvelle dans le cas de sys_fork). Par la suite, nous supposons être capable de capturer le début et la fin de tout appel. À noter qu il est possible d implanter un tel module dans n importe quel noyau [3]. Un évènement observable (Définition 1) est un évènement atomique vu par un observateur. Tous les évènements observables font parti de l ensemble OE (SC EOP SC) où EOP est l ensemble des opérations élémentaires (début_lire, début_écrire, fin_lire,... ). Le triplet (a, eop, b) décrit l opération eop du contexte a vers b. { a, b SC Définition 1 (Évènement observable) oe OE def (a, eop, b) où eop EOP Une trace de bas niveau (Définition 2) produite par le système est un ensemble d évènements observables. La Figure 1a montre un exemple de trace d un système composé de trois entités (a, b, c), une opération de lecture est terminée et une opération d écriture est toujours en cours (pas d évènement de fin). Définition 2 (Trace d évènements observables) T def {oe 1, oe 2,..., oe n } où oe i OE (a) Trace d évènements observables (b) Trace d évènements fonctionnels (c) Trace de flux d information FIGURE 1 Les trois types de traces 3.2. Traces d évènements fonctionnels À partir des évènements de début et de fin, nous pouvons obtenir l évènement fonctionnel correspondant (Définition 3) comprenant l opération fonctionnelle telle que lire, écrire. Une en-

5 tité peut réaliser plusieurs opérations en parallèle. Supposons un contexte a effectuant deux lectures d un contexte b ; par exemple deux entités avec le contexte a lisent un fichier avec le contexte b. Pour associer correctement les évènements de début et de fin, un observateur doit distinguer les deux opérations parallèles de lecture, notamment dans le cas où les sources et les destinations sont identiques. Ainsi, nous supposons deux fonctions est_évènement_début et est_évènement_fin, déterminant respectivement si un évènement observable oe i est le début d une opération fonctionelle op et si un évènement observable oe j est la fin d une opération op commençant avec oe i. Tous les évènements d une trace fonctionnelle (Définition 4) sont dans l ensemble FE (SC FO SC) et toutes les opérations fonctionnelles dans l ensemble FO. Les deux fonctions est_évènement_début et est_évènement_fin sont définies comme suit : est_évènement_début : OE FO {true, false} est_évènement_fin : OE OE {true, false} Définition 3 (Évènement fonctionnel) a, b SC, op FO k [i, j], (a, op, b) k FE def i i, oe i = (a, eop début, b) i est_évènement_début(oe i, op) j j, oe j = (a, eop fin, b) j est_évènement_fin(oe j, oe i ) La notation (a, op, b) k décrit une opération op de a sur b à l instant k. Définition 4 (Trace d évènements fonctionnels) T def {fe 1, fe 2,..., fe n } où fe i FE La Figure 1b illustre le résultat de la projection des évènements observables de la Figure 1a en évènements fonctionnels. Dans cette trace, le premier évènement observable (a, début_lire, b) et le troisième (a, fin_lire, b) sont transformés en un évènement fonctionnel (a, lire, b) ayant lieu à tout instant du début à la fin (inclus) Traces de flux d information Les différents modèles de flux d information diffèrent de part leur expressivité et leurs relations. Cependant, nous pouvons extraire deux relations/opérations communes : La relation propagation vers. Par exemple, une information se propage de a vers b. L opération re-labellisation. Par exemple, une entité labellisée avec a est re-labellisée avec b. Une opération de re-labellisation initiée par une entité est appelé une transition ; par exemple, une entité souhaite transiter du contexte a vers b. Nous considérons trois relations dans nos traces de flux d information : Un flux de a vers b est défini par (a > b). Un anti-flux (l absence de flux) de a vers b est défini par (a b). Une transition de a vers b est définie par (a > t b). Pour transformer des évènements fonctionnels en flux d information, nous introduisons trois fonctions déterminant si une opération fonctionnelle (op FO) est équivalente à une opération lire, écrire ou transiter. est_type_lire, est_type_écrire, est_type_transiter : FO {true, false} Les définitions 5, 6 définissent formellement les deux relations (>, > t ) à partir des fonctions est_type_lire, est_type_écrire, est_type_transiter, la relation étant simplement la négation de >. Tous les évènements d une trace d IF sont inclus dans l ensemble IF.

6 Définition 5 (Relation flux vers) ((b, op, a) est_type_lire(op)) (a > b) IF def op FO ((a, op, b) est_type_écrire(op)) Définition 6 (Relation transition) (a > t b) IF def op FO((a, op, b) est_type_transiter(op)) La Figure 1c illustre le résultat de la projection des évènements fonctionnels de la Figure 1b en flux d information. (a, lire, b) et (c, écrire, b) sont substitués respectivement par (a < b) and (c > b). 4. Propriétés de sécurité : une logique temporelle Un ensemble de traces d exécution d un système est soit généré statiquement à partir d un modèle (sous forme d automate, de réseau de pétri, etc.) soit dynamiquement produit à l exécution. Dans le cas statique, nous obtenons un ensemble de traces (potentiellement) infinies représentant toutes les exécutions possibles vues par un observateur. Dans le cas dynamique, nous obtenons une trace finie par observateur représentant l historique de l exécution courante. Nous présentons dans cette section la syntaxe et sémantique de notre logique temporelle multisortée avec flux d information devant prendre en compte indifféremment les deux cas Logique temporelle multi-sortée avec flux d information Pour modéliser les propriétés de trace, nous utilisons une logique temporelle multi-sortée du premier ordre sur des flux d information. Une logique temporelle définie implicitement l écoulement du temps au cours duquel les formules sont évaluées. Une logique du premier ordre permet l utilisation de quantificateurs pour exprimer des propriétés telles que : Il existe un contexte a depuis lequel un flux est initié. Enfin, une logique multi-sortée, par opposition avec une logique monosorté, permet de définir plusieurs sortes de domaines au lieu d un unique domaine de définition sur lequel les quantificateurs itèrent. La notion de sortes permet de différencier les contextes des domaines sans recourir à une logique du second ordre. Ci-dessous, nous donnons la définition générale d une signature multi-sortée, c est-à-dire les symboles non-logiques (d une logique multi-sortée), puis détaillons la signature concrète de notre logique IF-PLTL. Décrivons tout d abord une signature multi-sortée (Définition 7). Définition 7 (Signature multi-sortée) Une signature multi-sortée est un t-uplet Σ = (S, C, F, P) où : S = {σ 1,..., σ n } où n > 0 et σ i est une sorte. C = {c 1,..., c n } où n 0 et c i est un symbole de constante de sorte σ S. F = {f 1,..., f n } où n 0 et f i est un symbole de fonction d arité m 0 de sortes (σ 1... σ m ) σ où σ i S et σ S. P = {p 1,..., p n } où n 0 et p i est un symbole de prédicat d arité m 0 de sortes (σ 1... σ m ) où σ i S. Les informations de temps peuvent être rendues implicites avec les modalités de PLTL (LTL Passé) [13]. (P-)LTL est un formalisme courant pour exprimer des propriétés de sûreté et de vivacité dans un système concurrent. Clarkson et al. [6] ont démontré qu une propriété de

7 sécurité est une intersection entre une propriété de sûreté et une propriété de vivacité. Alors qu une logique multi-sortée est bien adaptée à la spécification de propriétés d IF, (P-)LTL est bien adapté pour exprimer des propriétés d IF temporelles Syntaxe d IF-PLTL La syntaxe décrit comment construire une formule bien-formée de notre logique. Une formule est dite bien-formée si elle fait partie de notre langage formel. Autrement dit, une formule malformée ne peut être interprétée par notre système. Tout d abord, nous donnons la signature multi-sortée pour des flux d information temporels (Σ IF PLTL ), puis nous décrivons les règles de formation. Σ IF PLTL = (S, C, F, P) avec, {>,,, > t : ctx ctx S = {ctx, dom}, C =, F =, P =, / : ctx domain, / : domain domain} Nous considérons deux sortes ctx et dom pour désigner respectivement des contextes et des domaines (ensembles de contextes). Tout comme pour des traces d IF, les relations d IF (>,, > t ) sont naturellement définies entre contextes. De plus, nous introduisons la relation de flux indirect ( ) sémantiquement différent d un flux direct (>). Ce flux indirect n existe pas dans une trace d IF ; il est inféré à partir d une séquence de flux directs. Par exemple, la trace d IF de la Figure 1c satisfait la propriété c a aux deuxième et troisième instants de part l indirection c > b et b > a. Les relations d appartenance ensembliste (, / ) sont, premièrement, définies entre un contexte et un domaine, mais également entre domaines pour permettre la spécification d ensembles hiérarchiques. Par exemple, supposons un contexte a, un domain Set et un domain SuperSet, nous pouvons définir des relations hiérarchiques avec a Set est vrai, Set SuperSet est vrai et a SuperSet est faux. Ci-dessous, nous détaillons les règles de formations. x σ est une variable de sorte σ. c σ est un symbole de contante de sorte σ. Σ-TERM t ::= x σ c σ f(t 1,..., t n ) où f : σ 1... σ n σ est un symbole de fonction avec Σ-TERM t i de sorte σ i. Σ-ATOM a ::= p(t 1,..., t n ) où p : σ 1... σ n est un symbole de prédicat avec t i Σ-TERM de sorte σ i. Σ-FORMULAE ϕ ::= a ϕ ϕ 1 ϕ 2 ϕ 1 ϕ 2 ϕ 1 ϕ 2 ϕ 1 ϕ 2 σ xϕ(x) σ xϕ(x) X(ϕ) Y(ϕ) ϕ 1 Uϕ 2 ϕ 1 Sϕ 2 où a est un Σ-ATOM et x une variable de sorte σ. Les quatre modalités dérivées sont définies comme suit : Fϕ Uϕ Gϕ F ϕ Pϕ Sϕ Hϕ P ϕ Xϕ (Next) et Yϕ (Previous) sont vrais si ϕ est satisfait respectivement à l instant précédant et à l instant suivant. ϕ 1 Uϕ 2 (Until) est vrai si ϕ 1 est satisfait jusqu à ce que ϕ 2 le soit, ϕ 1 Sϕ 2 (Since) étant l équivalent passé. Nous donnons trois abréviations pour simplifier l expression des formules : ( x y)ϕ(x) ( x)(x y) ϕ(x) ( x y)ϕ(x) ( x)(x y) ϕ(x) (a / s) (a s) Pour simplifier la notation, nous supposerons les sortes comme implicitement définies. Par exemple, dans la formule ( a, b)(a > b), a, b sont de sorte ctx, la relation > n étant définie qu entre deux contextes.

8 Nom Séquent Flux intransitif (a > b) i (b > c) j, i j (a c) j L intérêt de règles de Introduction de l anti-flux (a > b) i (a b) i déduction est de pouvoir réaliser des preuves Implication du flux de transition (a > t b) i (a > b) i Élimination de l anti-flux (a b) i (a > b) i et théorèmes comme Flux de transition transitif (a > t b) i (b > t c) i (a > t c) i prouver l équivalence TABLE 1 Arguments dérivés entre deux formules. Nous disposons de toutes les règles classiques de la logique du premier ordre (Système dit d Hilbert), de PLTL et la Table 1 décrit les arguments pour les quatre relations sur les flux d information (>,, > t, ). La notation simplifiée (a > b) i décrit la relation > entre les variables a, b (de sorte implicite ctx) au moment i Sémantique d IF-PLTL La sémantique décrit comment évaluer une formule arbitraire bien-formée d IF-PLTL. Tout d abord, nous définissons ce qu est une structure multi-sortée du premier ordre (Définition 8) obtenue à chaque moment de l exécution ; il n y a pas de notion de temps dans cette structure. Puis, nous définissons une structure temporelle du premier ordre (Définition 9) interprétant l écoulement du temps. Ensuite, nous donnons la définition de la relation de satisfaction ( =) entre une structure IF-PLTL et une formule IF-PLTL. Enfin, nous illustrons ce qu est une interprétation avec l exemple de la propriété de non-interférence. Une structure multi-sortée du premier ordre M est composée d un domaine D et d une fonction d interprétation I. Le domaine est l ensemble de tous les objets de sortes ctx, dom. La fonction d interprétation définit la signification de tous les symboles pouvant apparaître dans une formule (sans les modalités temporelles). Définition 8 (Structure multi-sortée du premier ordre) Une Σ IF PLTL -structure (ou modèle) temporelle du premier ordre est un t-uplet M = (D, I) avec : 1. D = σ S D σ un domaine multi-sorté avec D σ un domaine non-vide. σ 1, σ 2 S, D σ1 D σ2 =. 2. I une fonction d interprétation sur D satisfaisant les propriétés suivantes : (a) Toute sorte σ S est projetée vers un domaine non-vide D σ. (b) Tout symbole de constante c C de sorte σ est projeté vers un élément c I D σ. (c) Tout symbole de fonction f F d arité σ 1... σ n σ est projeté vers une fonction f I : D σ1... D σn D σ. (d) Tout symbole de prédicat p P d arité σ 1... σ n est projeté vers un sous-ensemble p I D σ1... D σn. Une structure temporelle du premier ordre M est composée de l écoulement du temps F, du même domaine D et d une fonction A associant à tout moment de l exécution une structure multi-sortée du premier ordre telle qu introduite précédemment. Définition 9 (Structure temporelle du premier-ordre) Une Σ IF PLTL -structure (ou modèle) temporelle du premier ordre est définie par M = F, D, A avec : 1. F = T, < une ordre linéaire strict représentant l écoulement du temps avec T N. 2. D = σ S D σ un domaine multi-sorté avec D σ un domaine non-vide. σ 1, σ 2 S, D σ1 D σ2 =. 3. A une fonction associant à tout moment k T une structure multi-sortée du premier ordre A(k) = D, I k avec I k l interprétation au moment k.

9 Nous utilisons la notation (M, k) pour désigner une structure multi-sortée du premier ordre au moment k. La relation de satisfaction (ou de vérité) (M, k) = ϕ entre un modèle (structure) M et une formule ϕ au moment k est definie comme suit : (M, k) = (a > b) ssi (a > b) I k (>) (M, k) = (a > t b) ssi (a > t b) I k (> t ) (M, k) = (a s) ssi (a s) I k ( ) (M, k) = (a b) ssi (M, k) = (a > b) (M, j) = (c > b) (M, k) = (a b) ssi i, j, (0 i j k), ctx c et (M, i) = (a > c) (a c) (M, k) = ϕ ssi (M, k) = ϕ (M, k) = ϕ 1 ϕ 2 ssi (M, k) = ϕ 1 et (M, k) = ϕ 2 (M, k) = ϕ 1 ϕ 2 ssi (M, k) = ϕ 1 ou (M, k) = ϕ 2 (M, k) = ϕ 1 ϕ 2 ssi (M, k) = ϕ 1 ou (M, k) = ϕ 2 (M, k) = ϕ 1 ϕ 2 ssi (M, k) = ϕ 1 ϕ 2 et (M, k) = ϕ 2 ϕ 1 (M, k) = σ xϕ(x) ssi (M, k) = ϕ[x I /x] pour tout x I D σ (M, k) = σ xϕ(x) ssi (M, k) = ϕ[x I /x] pour un x I D σ (M, k) = Xϕ ssi k + 1 < T et (M, k + 1) = ϕ (M, k) = Yϕ ssi 0 < k et (M, k 1) = ϕ (M, i) = ϕ 2 (M, k) = ϕ 1 Uϕ 2 ssi i, (k i < T ), et j, (k j < i), (M, j) = ϕ 1 (M, i) = ϕ 2 (M, k) = ϕ 1 Sϕ 2 ssi i, (0 i k), et j, (i < j k), (M, j) = ϕ 1 Isolation et Non-interférence Un problème majeur dans les Clouds concerne l isolation des tenants. Goguens et Meyers [9] définissent la propriété d isolation à partir de deux propriétés de non-interférence. Les auteurs dénotent par D 1 : D 2 qu un groupe d utilisateurs D 1 n interfère pas avec un groupe d utilisateurs D 2 et l isolation entre D 1 et D 2 est définie comme une non-interférence mutuelle, soit D 1 : D 2 et D 2 : D 1. En terme de flux d information, la propriété de non-interférence D 1 : D 2 signifie que l information ne peut, directement ou indirectement, se propager de D 1 vers D 2, ce qui peut être traduit par u 1 D 1, u 2 D 2, ((u 1 u2) (u 1 > u 2 )). Illustrons maintenant l interprétation avec la propriété FIGURE 2 Scénario d IF avec trois groupes (D 1, D 2, D 3 ) et six entités (a, b, c, d, e, f) de non-interférence. Supposons le scénario représenté par la Figure 2. Cette figure doit être lue comme suit : À l instant 1, l information se propage de a vers b, puis à l instant 2 de f vers e, et ainsi de suite aux instants 3 et 4. À l instant 5, il y a une transition de c vers f signifiant que l entité labellisée avec c souhaite être re-labellisée avec f. La Table 2 détaille pour tout moment k l interprétation de chaque relation (>, > t, ).

10 Instant k Trace (a > b) (f > e) (b > f) (f > d) (c > t f) I k (>) {(a > b)} {(f > e)} {(b > f)} {(f > d)} {(c > f)} I k (> t) {(c > t f)} I k ( ) D 1 = {a, b, c} idem idem idem idem D 2 = {d, e} D 3 = {f} D 1 : D 2 true true true false true TABLE 2 Interprétation et satisfaction de la non-interférence entre D 1 et D 2. Nous avons motivé l utilisation d une logique temporelle multi-sortée avec flux d information et introduit la syntaxe/sémantique de IF-PLTL. De plus, nous avons montré comment spécifier la propriété de non-interférence en IF-PLTL et comment la vérifier sur une trace d IF. 5. Dynamicité : opérateurs sur les ensembles Comme illustré par l exemple de la non-interférence (Figure 2 et Table 2), l interprétation de la relation ensembliste ( ) est identique à tout moment k. De plus, il n y a ni fonction ni relation permettant de changer cette interprétation durant l exécution, c est-à-dire de modifier l appartenance à un ensemble. Ci-après, nous présentons une politique, l isolation des domaines, où des ensembles dynamiques peuvent présenter un intérêt, puis nous détaillons notre proposition basée sur des annotations de formules. Enfin, nous décrivons la politique d isolation dynamique des domaines. En effet, les ensembles dynamiques sont nécessaires pour augmenter la flexibilité des propriétés et ainsi permettre la prise en compte de la dynamicité des systèmes. Supposons une politique d isolation des domaines stricte définie par la propriété 1 où deux entitités (a, b) peuvent échanger des informations si elles sont dans le même domaine (Dom i ). Avec une telle politique, une entité n appartenant à aucun domaine ne peut pas envoyer d information à quiconque. Ainsi, toutes les entités du système doivent être correctement labellisées avec un domaine, ce qui est une tâche complexe et chronophage. Propriété 1 (Isolation des domaines) DI(DOMs) ( a, b)g((a > b) ( Dom i DOMs)(a, b Dom i )) FIGURE 3 Scénario avec différents départements pour une isolation dynamique des domaines. Considérons le scénario décrit par la Figure 3. Une compagnie externalise ses services dans le Cloud. Cette compagnie est composée de deux départements, R&D et ressources humaines (RH), et chaque département possède des données confidentielles. Le département de R&D possède une base de donnée pour un gestionnaire de projet (données_project). Le département des RH possède toutes les données privées des employés (données_employés). Dû à la branche R&D, la société doit tester des versions d un logiciel (app_nonstable) qui sont donc non sûres et doivent être isolées du reste des services. Par ailleurs, la compagnie teste régulièrement des logiciels externes dans lequels elle n a pas totalement confiance (app_nonfiable). Enfin, la société dispose de plusieurs applications (app1_entreprise, app2_entreprise) pouvant varier

11 au fil du temps (par exemple, ajout d une app3_entreprise). La politique de l entreprise définit qu une application ne peut accéder à la fois aux domaines R&D et RH mais sans connaître a priori quelle application accède à quelles données. L idée est donc de contaminer les applications avec le domaine auquel elles appartiennent selon le premier accès réalisé. Par exemple, si app1_entreprise accède à données_project, elle fera partie du domaine R&D. Notre politique d isolation dynamique des domaines est décomposée en trois propriétés. Supposons DOMs contenant les domaines et les bacs à sable, alors l information peut se propager d un contexte a vers un contexte b si : 1. a, b appartiennent au même ensemble Dom i (de DOMs). Cette contrainte correspond à l isolation statique des domaines (propriété 1). 2. ou a n appartient à aucun ensemble. 3. ou a appartient à Dom i et b n appartient à aucun ensemble, alors b devient membre de Dom i. Nous proposons la syntaxe ϕ[[annotation]] signifiant que Annotation est effectué lorsque ϕ est vrai. Une annotation pour modifier l appartenance à des ensembles serait donc [[S S {x}]], c est-à-dire x devient membre de S. La propriété 2 traduit les trois propriétés précédentes en IF-PLTL. Propriété 2 (Isolation dynamique des domaines) DI(DOMs) ( a, b)g((a > b) ( Dom i DOMs)(a / Dom i )) DDI(DOMs) ( a, b)( Dom i DOMs)G ( ((a > b) (a Dom i ) ( Dom j DOMs)(b / Dom j )) [Dom i Dom ) i {b} ] Ainsi, nous avons contruit une propriété d isolation dynamique des domaines (DDI). Un client IaaS doit donc simplement appeler la fonction DDI avec son paramètre DOMs ; par exemple, DDI({R&D, R&H, Env.Test, Autres}). Nous avons montré les bénéfices de l utilisation d annotations pour étendre notre logique avec des ensembles dynamiques. De plus, les annotations peuvent être utilisées pour spécifier des capacités actives de l observateur (qui n est donc plus passif ) ne se limitant pas à l exemple des ensembles dynamiques. 6. Conclusion Tout d abord, nous avons motivé le besoin d un langage d IFC formel pour des systèmes distribués et montré la différence entre notre approche et les précédentes. Puis, nous avons présenté notre langage formel permettant l expression de propriétés de sécurité avancées contrôlant différents types de flux d information : directs, transitifs et intransitifs. En utilisant ces opérateurs, notre Information Flow Past Linear Time Logic (IF-PLTL) permet l expression de diverses propriétés ou politiques de sécurité telles que la non-interférence. De plus, nous avons montré comment construire une trace d IF à partir des évènement de bas niveau d un système. Pour faciliter l utilisation d IF-PLTL, nous avons proposé une API de haut niveau pouvant être utilisée et paramétrée par des clients IaaS pour exprimer leurs objectifs de sécurité. Enfin, nous avons montré comment étendre IF-PLTL pour prendre en compte la dynamicité des systèmes et proposé une nouvelle politique de sécurité nommée isolation dynamique des domaines. Par la suite, nous proposerons des méthodes pour assurer la composabilité des différentes propriétés. Nous travaillerons également sur le découpage de propriétés IF-PLTL pour un ensemble d observateurs collaboratifs, en particulier des observateurs à différents niveaux du Cloud (IaaS, PaaS, SaaS). Enfin, une étude intéressante serait de déterminer la cohérence (ou non) d une théorie exprimée en IF-PLTL.

12 Bibliographie 1. Bacon (J.), Evans (D.), Eyers (D. M.), Migliavacca (M.), Pietzuch (P.) et Shand (B.). Enforcing End-to-End Application Security in the Cloud (Big Ideas Paper). In Proceedings of the ACM/IFIP/USENIX 11th International Conference on Middleware, Middleware 10, Middleware 10, pp , Berlin, Heidelberg, Springer-Verlag. 2. Basin (D.), Klaedtke (F.) et Müller (S.). Policy monitoring in first-order temporal logic. In : Computer Aided Verification, éd. par Touili (T.), Cook (B.) et Jackson (P.), pp Springer Berlin Heidelberg, janvier Blanc (M.), Bousquet (A.), Briffaut (J.), Clevy (L.), Gros (D.), Lefray (A.), Rouzaud-Cornabas (J.), Toinard (C.) et Venelle (B.). Mandatory access protection within cloud systems. In : Security, Privacy and Trust in Cloud Systems, éd. par Nepal (S.) et Pathan (M.), pp Springer Berlin Heidelberg, Briffaut (J.), Peres (M.), Rouzaud Cornabas (J.), Solanki (J.), Toinard (C.) et Venelle (B.). PIGA-OS : Retour sur le Système d Exploitation Vainqueur du Défi Sécurité. In 8ème Conférence Française en Systèmes d Exploitation, St Malo, France, Caron (E.), Desprez (F.) et Rouzaud-Cornabas (J.). Smart resource allocation to improve cloud security. In : Security, Privacy and Trust in Cloud Systems, éd. par Nepal (S.) et Pathan (M.), pp Springer Berlin Heidelberg, Clarkson (M. R.) et Schneider (F. B.). Hyperproperties. J. Comput. Secur., vol. 18, n6, septembre 2010, pp Clemente (P.), Rouzaud-Cornabas (J.) et Toinard (C.). From a generic framework for expressing integrity properties to a dynamic mac enforcement for operating systems. In : Transactions on Computational Science XI, éd. par Gavrilova (M.), Tan (C.) et Moreno (E.), pp Springer Berlin Heidelberg, Dimitrova (R.), Finkbeiner (B.), Kovács (M.), Rabe (M. N.) et Seidl (H.). Model checking information flow in reactive systems. In : Verification, Model Checking, and Abstract Interpretation, éd. par Kuncak (V.) et Rybalchenko (A.), pp Springer Berlin Heidelberg, janvier Goguen (J. A.) et Meseguer (J.). Security policies and security models. In IEEE Symposium on Security and privacy, Halpern (J. Y.) et Weissman (V.). Using first-order logic to reason about policies. ACM Trans. Inf. Syst. Secur., vol. 11, n4, juillet 2008, p. 21 :1 21 : Kafura (D.) et Gracanin (D.). An information flow control meta-model. In Proceedings of the 18th ACM Symposium on Access Control Models and Technologies, SACMAT 13, SACMAT 13, p , New York, NY, USA, ACM. 12. Lamport (L.). Specifying concurrent program modules. ACM Trans. Program. Lang. Syst., vol. 5, n2, avril 1983, p Pnueli (A.). The temporal logic of programs. In the 18th Annual Symposium on Foundations of Computer Science, 1977, pp , Rodero-Merino (L.), M. Vaquero (L.), Caron (E.), Desprez (F.) et Muresan (A.). Building safe paas clouds : a survey on security in multitenant software platforms. Computers & Security, vol. 31, 2012, pp Rushby (J.). Security requirements specifications : How and what. In Symposium on Requirements Engineering for Information Security (SREIS), Sandhu (R.), Boppana (R.), Krishnan (R.), Reich (J.), Wolff (T.) et Zachry (J.). Towards a Discipline of Mission-Aware Cloud Computing. In Proceedings of the 2010 ACM workshop on Cloud computing security workshop, pp , 2010.

Analyse abstraite de missions sous PILOT

Analyse abstraite de missions sous PILOT Analyse abstraite de missions sous PILOT Damien Massé EA 3883, Université de Bretagne Occidentale, Brest damien.masse@univ-brest.fr Résumé Nous étudions la possibilité de réaliser un analyseur par interprétation

Plus en détail

et Automates de Büchi

et Automates de Büchi Cours 9: Propriétes ω-régulières et Automates de Büchi Francesco Belardinelli Laboratoire IBISC Remerciements à Alessio Lomuscio et Joost-Pieter Katoen 26 mars 2015 Cours 9 - Vue d Ensemble Motivation

Plus en détail

Security Properties for the Application Control within a Linux Kernel (SPACLik aka PIGA-OS)

Security Properties for the Application Control within a Linux Kernel (SPACLik aka PIGA-OS) Security Properties for the Application Control within a Linux Kernel (SPACLik aka PIGA-OS) Jérémy Briffaut, Martin Peres, Jonathan Rouzaud-Cornabas, Jigar Solanki, Christian Toinard, Benjamin Venelle

Plus en détail

AVATAR. Un profil SysML temps réel outillé

AVATAR. Un profil SysML temps réel outillé AVATAR Un profil SysML temps réel outillé Ludovic Apvrille, Pierre de Saqui-Sannes ludovic.apvrille@telecom-paristech.fr pdss@isae.fr SysML France, 6 décembre 2010 Agenda De TURTLE à AVATAR Le langage

Plus en détail

Retour sur dix années de recherche sur la protection des systèmes d exploitation

Retour sur dix années de recherche sur la protection des systèmes d exploitation Retour sur dix années de recherche sur la protection des systèmes d exploitation Christian Toinard ENSI de Bourges/LIFO JIRC 29 Mai 2013 Christian Toinard (ENSIB/LIFO) 1/14 Objectifs de l exposé L histoire

Plus en détail

Introduction au model-checking et application à la vérification des protocoles cryptographiques

Introduction au model-checking et application à la vérification des protocoles cryptographiques Introduction au model-checking et application à la vérification des protocoles cryptographiques Prof. John MULLINS École Polytechnique de Montréal Prof. John MULLINS (École Polytechnique) Introduction

Plus en détail

Partie I : Automates et langages

Partie I : Automates et langages 2 Les calculatrices sont interdites. N.B. : Le candidat attachera la plus grande importance à la clarté, à la précision et à la concision de la rédaction. Si un candidat est amené à repérer ce qui peut

Plus en détail

Vers l intégration automatique d une politique de sécurité Or-BAC

Vers l intégration automatique d une politique de sécurité Or-BAC 315 Prépublication n 48 Fascicule n 2 Vers l intégration automatique d une politique de sécurité Or-BAC Yliès Falcone, Mohamad Jaber Vérimag & Laboratoire d Informatique de Grenoble Ylies.Falcone@imag.fr,

Plus en détail

Support du cours de Probabilités IUT d Orléans, Département d informatique

Support du cours de Probabilités IUT d Orléans, Département d informatique Support du cours de Probabilités IUT d Orléans, Département d informatique Pierre Andreoletti IUT d Orléans Laboratoire MAPMO (Bât. de Mathématiques UFR Sciences) - Bureau 126 email: pierre.andreoletti@univ-orleans.fr

Plus en détail

Correction de programmes : Logique de Hoare

Correction de programmes : Logique de Hoare 16 juillet 2009 Logique et informatique Vis-à-vis de l informatique la logique a au moins 2 rôles : 1 Externe et théorique (fondements de l informatique - Électif en S4) : Logique comme méta-informatique

Plus en détail

UPMC Master informatique 2 STL NI503 Conception de langages Notes I

UPMC Master informatique 2 STL NI503 Conception de langages Notes I UPMC Master informatique 2 STL NI503 Conception de langages Notes I 2012 1 Évaluer Un langage Le langage Logo est composé commandes permettant de diriger le déplacement d un point sur un plan cartésien

Plus en détail

Automatisation de la certification formelle de systèmes critiques par instrumentation d interpréteurs abstraits

Automatisation de la certification formelle de systèmes critiques par instrumentation d interpréteurs abstraits 1 d Automatisation de la certification formelle de systèmes critiques par instrumentation d sous la direction de Michaël Périn Soutenance de Thèse de Doctorat Université de Grenoble - Laboratoire Verimag

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

Épreuve d informatique 2011

Épreuve d informatique 2011 A 2011 INFO. MP ÉCOLE NATIONALE DES PONTS ET CHAUSSÉES, ÉCOLES NATIONALES SUPÉRIEURES DE L AÉRONAUTIQUE ET DE L ESPACE, DE TECHNIQUES AVANCÉES, DES TÉLÉCOMMUNICATIONS, DES MINES DE PARIS, DES MINES DE

Plus en détail

UNIVERSITE D ORLEANS SL01MA11, Groupes 1 et 5 Département de Mathématiques 2009-2010. N. El Hage Hassan S EXPRIMER EN MATHÉMATIQUES

UNIVERSITE D ORLEANS SL01MA11, Groupes 1 et 5 Département de Mathématiques 2009-2010. N. El Hage Hassan S EXPRIMER EN MATHÉMATIQUES UNIVERSITE D ORLEANS SL01MA11, Groupes 1 et 5 Département de Mathématiques 2009-2010 N. El Hage Hassan S EXPRIMER EN MATHÉMATIQUES 1 Les énoncés La plupart des phrases que l on rencontre dans un livre

Plus en détail

Service combinators for farming virtual machines

Service combinators for farming virtual machines Master d Informatique Fondamentale École Normale Supérieure de Lyon Sémantique du parallélisme Chantal Keller Service combinators for farming virtual machines K. Bhargavan, A. D. Gordon, I. Narasamdya

Plus en détail

Points fixes de fonctions à domaine fini

Points fixes de fonctions à domaine fini ÉCOLE POLYTECHNIQUE ÉCOLE NORMALE SUPÉRIEURE DE CACHAN ÉCOLE SUPÉRIEURE DE PHYSIQUE ET DE CHIMIE INDUSTRIELLES CONCOURS D ADMISSION 2013 FILIÈRE MP HORS SPÉCIALITÉ INFO FILIÈRE PC COMPOSITION D INFORMATIQUE

Plus en détail

Examen CAR 2 Heures Tout documents autorisés le 17 Novembre 2005

Examen CAR 2 Heures Tout documents autorisés le 17 Novembre 2005 Examen CAR 2 Heures Tout documents autorisés le 17 Novembre 2005 Rappel : Tout méta-modèle ou profil doit être commenté! 1 Question de compréhension du cours barème indicatif : 5 points Q : Lorsque l on

Plus en détail

Contexte général de l étude

Contexte général de l étude 1 2 Contexte général de l étude Les entrepôts de données associés à des outils d analyse On Line Analytical Processing (OLAP), représentent une solution effective pour l informatique décisionnelle (Immon,

Plus en détail

Résolution générique à la volée de systèmes d équations booléennes et applications

Résolution générique à la volée de systèmes d équations booléennes et applications Résolution générique à la volée de systèmes d équations booléennes et applications Radu Mateescu INRIA Rhône-Alpes / VASY Plan Introduction Systèmes d équations booléennes d alternance 1 Algorithmes de

Plus en détail

Chapitre 3. Définitions récursives et induction structurelle

Chapitre 3. Définitions récursives et induction structurelle Chapitre 3 Définitions récursives et induction structurelle 114 Plan 1. Définitions récursives 2. Induction structurelle 3. Exemples Arbres Naturels Expressions arithmétiques Lectures conseillées : I MCS

Plus en détail

5 Moniteurs. Slide 1. Caractéristique majeure d un programme avec moniteurs = Composé de deux sortes de modules/processus: Slide 2

5 Moniteurs. Slide 1. Caractéristique majeure d un programme avec moniteurs = Composé de deux sortes de modules/processus: Slide 2 5 Moniteurs Motivation = les sémaphores peuvent être utilisés pour résoudre à peu près n importe quel problème d exclusion mutuelle ou synchronisation... mais, les sémaphores possèdent certains désavantages:

Plus en détail

Évaluation et implémentation des langages

Évaluation et implémentation des langages Évaluation et implémentation des langages Les langages de programmation et le processus de programmation Critères de conception et d évaluation des langages de programmation Les fondations de l implémentation

Plus en détail

Customisation Rhapsody et Henri BOULOUET DITV/AEEV/EECH. approche méthodologique

Customisation Rhapsody et Henri BOULOUET DITV/AEEV/EECH. approche méthodologique Customisation Rhapsody et approche méthodologique Retour d expérience sur l implémentation d un langage et profil UML associé 1 Sommaire Principe d un développement méthodologique Evocation d ISR (Ingénierie

Plus en détail

Noureddine Kerzazi noureddine.kerzazi@polymtl.ca

Noureddine Kerzazi noureddine.kerzazi@polymtl.ca Domaine de la modélisation des processus pour le génie logiciel. Noureddine Kerzazi noureddine.kerzazi@polymtl.ca DSL4SPM Domain-Specific-Language for Software Process Modeling Il s agit d un nouveau cadre

Plus en détail

Systèmes linéaires. 1. Introduction aux systèmes d équations linéaires. Exo7. 1.1. Exemple : deux droites dans le plan

Systèmes linéaires. 1. Introduction aux systèmes d équations linéaires. Exo7. 1.1. Exemple : deux droites dans le plan Exo7 Systèmes linéaires Vidéo partie 1. Introduction aux systèmes d'équations linéaires Vidéo partie 2. Théorie des systèmes linéaires Vidéo partie 3. Résolution par la méthode du pivot de Gauss 1. Introduction

Plus en détail

Cours 4 : Contrôle d accès

Cours 4 : Contrôle d accès Cours 4 : Contrôle d accès ESIL Université de la méditerranée Odile.Papini@esil.univ-mrs.fr http://odile.papini.perso.esil.univmed.fr/sources/ssi.html Plan du cours 4 1 Introduction 2 3 4 4 5 6 7 Introduction

Plus en détail

Vidéo partie 1. Logique Vidéo partie 2. Raisonnements Exercices Logique, ensembles, raisonnements

Vidéo partie 1. Logique Vidéo partie 2. Raisonnements Exercices Logique, ensembles, raisonnements Exo7 Logique et raisonnements Vidéo partie 1. Logique Vidéo partie 2. Raisonnements Exercices Logique, ensembles, raisonnements Quelques motivations Il est important d avoir un langage rigoureux. La langue

Plus en détail

CSC4002 : Contrôle continu «Bureau d Étude noté» Date : lundi 3 décembre 2012 Durée : 2H. Coordonnateurs : Christian Bac et Denis Conan

CSC4002 : Contrôle continu «Bureau d Étude noté» Date : lundi 3 décembre 2012 Durée : 2H. Coordonnateurs : Christian Bac et Denis Conan Corrigé et Barème Contrôle de connaissances 2012/2013 des étudiants de 2 è année (EI2) CSC4002 : Contrôle continu «Bureau d Étude noté» Date : lundi 3 décembre 2012 Durée : 2H Coordonnateurs : Christian

Plus en détail

ACI Sécurité ALIDECS:

ACI Sécurité ALIDECS: ACI Sécurité ALIDECS: Langages et Atelier Integrés pour le Développement de Composants Embarqués Sûrs Réunion de démarrage LIP6, 21 et 22 octobre 2004 Marc Pouzet 1 Page web http://www-verimag.imag.fr/synchrone/alidecs/

Plus en détail

5SINF200 : Développement de programmes (A. Slissenko) Examen

5SINF200 : Développement de programmes (A. Slissenko) Examen Licence Info Corrigé 5SINF200 : Développement de programmes (A. Slissenko) Examen Le 21 décembre 2006, 13h30 15h30 Utilisation des notes, des livres, des docs, etc. autorisée. Ce corrigé contient des réponses

Plus en détail

Introduction aux Composants Logiciels

Introduction aux Composants Logiciels Introduction aux Composants Logiciels Christian Pérez LIP/INRIA Année 2010-11 Plan Introduction aux composants logiciels Pourquoi des composants logiciels Notions de composants logiciels Conclusion Survol

Plus en détail

Vérification Formelle des Aspects de Cohérence d un Workflow net

Vérification Formelle des Aspects de Cohérence d un Workflow net Vérification Formelle des Aspects de Cohérence d un Workflow net Abdallah Missaoui Ecole Nationale d Ingénieurs de Tunis BP. 37 Le Belvédère, 1002 Tunis, Tunisia abdallah.missaoui@enit.rnu.tn Zohra Sbaï

Plus en détail

Les limites théoriques de l informatique Les problèmes indécidables

Les limites théoriques de l informatique Les problèmes indécidables Les limites théoriques de l informatique Les problèmes indécidables Samuel Fiorini - Gilles Geeraerts - Jean-François Raskin Université Libre de Bruxelles Académie Royale des Sciences Bruxelles 3/3/2010

Plus en détail

Conditions Générales d'utilisation - YOUSIGN SAS - SIGN2 CA

Conditions Générales d'utilisation - YOUSIGN SAS - SIGN2 CA Conditions Générales d'utilisation - YOUSIGN SAS - SIGN2 CA 1- Introduction 1.1 Présentation générale Ce document définit les Conditions Générales d Utilisation (CGU) des certificats délivrés dans le cadre

Plus en détail

Le génie logiciel. maintenance de logiciels.

Le génie logiciel. maintenance de logiciels. Le génie logiciel Définition de l IEEE (IEEE 1990): L application d une approche systématique, disciplinée et quantifiable pour le développement, l opération et la maintenance de logiciels. Introduction

Plus en détail

Chapitre 2 Le problème de l unicité des solutions

Chapitre 2 Le problème de l unicité des solutions Université Joseph Fourier UE MAT 127 Mathématiques année 2011-2012 Chapitre 2 Le problème de l unicité des solutions Ce que nous verrons dans ce chapitre : un exemple d équation différentielle y = f(y)

Plus en détail

PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1

PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1 PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1 CYCLE de VIE des SYSTEMES INFORMATISES Expression du besoin Développement du «système» Exploitation

Plus en détail

Université Paris Diderot Master 1 II. Théorie et pratique de la concurrence

Université Paris Diderot Master 1 II. Théorie et pratique de la concurrence Université Paris Diderot Master 1 II Théorie et pratique de la concurrence Partiel du 30 avril 2009 Durée : 1h30. Tous les documents sont autorisés. Le barème est indicatif. Question 1 : Soit le programme

Plus en détail

Conception des systèmes répartis

Conception des systèmes répartis Conception des systèmes répartis Principes et concepts Gérard Padiou Département Informatique et Mathématiques appliquées ENSEEIHT Octobre 2012 Gérard Padiou Conception des systèmes répartis 1 / 37 plan

Plus en détail

MODELISATION ET VERIFICATION DE POLITIQUES DE SECURITE A L AIDE DE LA METHODE B

MODELISATION ET VERIFICATION DE POLITIQUES DE SECURITE A L AIDE DE LA METHODE B MODELISATION ET VERIFICATION DE POLITIQUES DE SECURITE A L AIDE DE LA METHODE B Amal HADDAD 1 ère année de thèse INPG LSR VASCO Directeurs : Mme. Marie Laure POTET M. Yves LEDRU Cadre du travail Problématique

Plus en détail

Espace de probabilité, indépendance et probabilité conditionnelle

Espace de probabilité, indépendance et probabilité conditionnelle Chapter 2 Espace de probabilité, indépendance et probabilité conditionnelle Sommaire 2.1 Tribu et événements........................................... 15 2.2 Probabilité................................................

Plus en détail

Protection et amélioration de la sécurité des systèmes d'exploitation

Protection et amélioration de la sécurité des systèmes d'exploitation Protection et amélioration de la sécurité des systèmes d'exploitation Jérémy Briffaut ENSI Bourges LIFO Martin Perès Université de Bordeaux LaBRI Jonathan Rouzaud-Cornabas INRIA Rhône Alpes Jigar Solanki

Plus en détail

Avant-propos. 1. Institut national de recherche en informatique et en automatique.

Avant-propos. 1. Institut national de recherche en informatique et en automatique. Avant-propos J ai découvert, un jour de 1986, l ouvrage de G. Fishman [FIS 73] sur la simulation au centre de documentation de l INRIA 1 à Rocquencourt. J ai été aussitôt attiré par ce procédé numérique

Plus en détail

Feuille 1 Modèle Relationnel et Requêtes Conjonctives

Feuille 1 Modèle Relationnel et Requêtes Conjonctives Université de Bordeaux M2 d Informatique, 2015-2016 Cours de Bases de Données Avancées Feuille 1 Modèle Relationnel et Requêtes Conjonctives Le but de cette feuille est d introduire le modèle de bases

Plus en détail

Développement itératif, évolutif et agile

Développement itératif, évolutif et agile Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie

Plus en détail

Le modèle de données relationnel

Le modèle de données relationnel Le modèle de données relationnel 1. Le modèle relationnel 1.1. Présentation Le modèle relationnel représente la base de données comme un ensemble de tables, sans préjuger de la façon dont les informations

Plus en détail

Nb de Pages : 11 Taille : 250 368 octets Version : 1.0. Référence : oepa_ieee730_20050120. Auteurs : Pierre Gallice

Nb de Pages : 11 Taille : 250 368 octets Version : 1.0. Référence : oepa_ieee730_20050120. Auteurs : Pierre Gallice OEPA Traduction de la norme IEEE 730 Nb de Pages : 11 Taille : 250 368 octets Version : 1.0 Référence : oepa_ieee730_20050120 Auteurs : Pierre Gallice Validé par : Antoine Tallon, chef de projet Destinataires

Plus en détail

Laboratoire 4 Développement d un système intelligent

Laboratoire 4 Développement d un système intelligent DÉPARTEMENT DE GÉNIE LOGICIEL ET DES TI LOG770 - SYSTÈMES INTELLIGENTS ÉTÉ 2012 Laboratoire 4 Développement d un système intelligent 1 Introduction Ce quatrième et dernier laboratoire porte sur le développement

Plus en détail

Logique et bases de données

Logique et bases de données Logique et bases de données Plan Théorie du premier ordre Hypothèses CWA, unique name, domain closure BD comme interprétation BD comme théorie du 1er ordre BD déductives Signification des différentes formes

Plus en détail

Introduction aux systèmes d exploitation

Introduction aux systèmes d exploitation Introduction aux systèmes d exploitation Le système d exploitation est un ensemble de logiciels qui pilotent la partie matérielle d un ordinateur. Les principales ressources gérées par un système d exploitation

Plus en détail

Enveloppes convexes dans le plan

Enveloppes convexes dans le plan ÉCOLE POLYTECHNIQUE ÉCOLES NORMALES SUPÉRIEURES ÉCOLE SUPÉRIEURE DE PHYSIQUE ET DE CHIMIE INDUSTRIELLES CONCOURS D ADMISSION FILIÈRE MP HORS SPÉCIALITÉ INFO FILIÈRE PC COMPOSITION D INFORMATIQUE B (XECLR)

Plus en détail

Use Cases. Introduction

Use Cases. Introduction Use Cases Introduction Avant d aborder la définition et la conception des UC il est bon de positionner le concept du UC au sein du processus de développement. Le Processus de développement utilisé ici

Plus en détail

Université Paris-Dauphine DUMI2E 1ère année, 2009-2010. Applications

Université Paris-Dauphine DUMI2E 1ère année, 2009-2010. Applications Université Paris-Dauphine DUMI2E 1ère année, 2009-2010 Applications 1 Introduction Une fonction f (plus précisément, une fonction réelle d une variable réelle) est une règle qui associe à tout réel x au

Plus en détail

introduction à la conception Orientée Objet

introduction à la conception Orientée Objet 1 introduction à la conception Orientée Objet IUP GEII 2ème année marcel@univ-tours.fr http://www.blois.univ-tours.fr/ marcel 2 plan cours 1. motivations génie logiciel 2. concepts et techniques orientés

Plus en détail

Systèmes d Information Avancés (et répartis)

Systèmes d Information Avancés (et répartis) Systèmes d Information Avancés (et répartis) Université Lyon 1 MIAGE L. Médini, mars 2005 Plan des cours Protocole HTTP et programmation serveur Architectures réparties Objets distribués Introduction aux

Plus en détail

Conventions communes aux profils UML

Conventions communes aux profils UML Conventions communes aux profils UML Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* Référence : Livrable 2.1 Date : Juin 2002 * : Les partenaires du

Plus en détail

Cours de Génie Logiciel

Cours de Génie Logiciel Cours de Génie Logiciel Sciences-U Lyon Diagrammes UML (2) http://www.rzo.free.fr Pierre PARREND 1 Avril 2005 Sommaire Les Diagrammes UML Diagrammes de Collaboration Diagrammes d'etats-transitions Diagrammes

Plus en détail

plate-forme PaaS (Audit)

plate-forme PaaS (Audit) Contrôle d accès dans une plate-forme PaaS (Audit) Ahmed BOUCHAMI, Olivier PERRIN, LORIA Introduction La sécurité d une plate-forme collaborative nécessite un module d authentification et un module de

Plus en détail

Introduction à l ISO/IEC 17025:2005

Introduction à l ISO/IEC 17025:2005 Introduction à l ISO/IEC 17025:2005 Relation avec d autres normes de Management de la Qualité Formation Assurance Qualité LNCM, Rabat 27-29 Novembre 2007 Marta Miquel, EDQM-CoE 1 Histoire de l ISO/IEC

Plus en détail

Vérification formelle d un modèle mémoire pour le langage C

Vérification formelle d un modèle mémoire pour le langage C Vérification formelle d un modèle mémoire pour le langage C Projet ANR ARA SSIA CompCert (http://compcert.inria.fr) Sandrine Blazy, Xavier Leroy CEDRIC-ENSIIE et INRIA Rocquencourt CEA-LIST, 18 mars 2008

Plus en détail

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009 GPA 789 : Analyse et Conception Orientées Objet ETS Mickaël Gardoni Bureau A 3588 tel 84 11 Mise en œuvre UML 1/ 25 Introduction Mise en œuvre d UML UML n est pas une méthode 2/ 25 1 UML n est qu un langage

Plus en détail

EXTENSION de Microsoft Dynamics CRM 2013. Réf FR 80452

EXTENSION de Microsoft Dynamics CRM 2013. Réf FR 80452 EXTENSION de Microsoft Dynamics CRM 2013 Réf FR 80452 Durée : 3 jours A propos de ce cours : Ce cours offre une information interactive et détaillée sur le développement d extensions pour Microsoft Dynamics

Plus en détail

Sémantique des Langages de Programmation

Sémantique des Langages de Programmation Sémantique des Langages de Programmation Introduction Stefano Guerrini stefano.guerrini@univ-paris13.fr LIPN - Institut Galilée, Université Paris Nord 13 Sup Galillée Informatique, 1ère année 2009 2010

Plus en détail

Automatisation des copies de systèmes SAP

Automatisation des copies de systèmes SAP Pour plus d informations sur les produits UC4 Software, visitez http://www.liftoff-consulting.com/ Automatisation des copies de systèmes SAP Introduction Le thème de la copie des systèmes SAP est une source

Plus en détail

INFO-F-302 Informatique Fondamentale Projet : Logique du Premier Ordre et Utilisation de l Outil Z3

INFO-F-302 Informatique Fondamentale Projet : Logique du Premier Ordre et Utilisation de l Outil Z3 UNIVERSITÉ LIBRE DE BRUXELLES (corrected version 20120416) INFO-F-302 Informatique Fondamentale Projet : Logique du Premier Ordre et Utilisation de l Outil Z3 L objectif de ce projet est de modéliser des

Plus en détail

Objectifs. Maîtriser. Pratiquer

Objectifs. Maîtriser. Pratiquer 1 Bases de Données Objectifs Maîtriser les concepts d un SGBD relationnel Les modèles de représentations de données Les modèles de représentations de données La conception d une base de données Pratiquer

Plus en détail

10 Prototypage rapide de logiciel pour les systèmes avioniques

10 Prototypage rapide de logiciel pour les systèmes avioniques Introduction Le contexte aéronautique 1 a depuis plusieurs années mis en évidence le besoin croissant de technologies de sécurité permettant d éviter des utilisations malveillantes des matériels ou services

Plus en détail

Modélisation des Systèmes d Information Jean-Yves Antoine

Modélisation des Systèmes d Information Jean-Yves Antoine Modélisation des Systèmes d Information Jean-Yves Antoine http://www.info.univ-tours.fr/~antoine Processus de développement logiciel Jean-Yves Antoine U. Bretagne Sud - UFR SSI - IUP Vannes année 2001-2002

Plus en détail

Traduction des Langages : Le Compilateur Micro Java

Traduction des Langages : Le Compilateur Micro Java BARABZAN Jean-René OUAHAB Karim TUCITO David 2A IMA Traduction des Langages : Le Compilateur Micro Java µ Page 1 Introduction Le but de ce projet est d écrire en JAVA un compilateur Micro-Java générant

Plus en détail

Primitives Cours maths Terminale S

Primitives Cours maths Terminale S Primitives Cours maths Terminale S Dans ce module est introduite la notion de primitive d une fonction sur un intervalle. On définit cette notion puis on montre qu une fonction admet une infinité de primitives

Plus en détail

UML (Paquetage) Unified Modeling Language

UML (Paquetage) Unified Modeling Language UML (Paquetage) Unified Modeling Language Sommaire Introduction Objectifs Paquetage Espace de nommage d un paquetage Dépendances entre paquetages 2 Notion introduite véritablement par UML car superficiellement

Plus en détail

Exclusion Mutuelle. Arnaud Labourel Courriel : arnaud.labourel@lif.univ-mrs.fr. Université de Provence. 9 février 2011

Exclusion Mutuelle. Arnaud Labourel Courriel : arnaud.labourel@lif.univ-mrs.fr. Université de Provence. 9 février 2011 Arnaud Labourel Courriel : arnaud.labourel@lif.univ-mrs.fr Université de Provence 9 février 2011 Arnaud Labourel (Université de Provence) Exclusion Mutuelle 9 février 2011 1 / 53 Contexte Epistémologique

Plus en détail

Formula Negator, Outil de négation de formule.

Formula Negator, Outil de négation de formule. Formula Negator, Outil de négation de formule. Aymerick Savary 1,2, Mathieu Lassale 1,2, Jean-Louis Lanet 1 et Marc Frappier 2 1 Université de Limoges 2 Université de Sherbrooke Résumé. Cet article présente

Plus en détail

6.1 Une classe simple pour représenter des comptes bancaires

6.1 Une classe simple pour représenter des comptes bancaires Chapitre 6 Héritage Ce chapitre du cours traite de concepts relatifs à la programmation objet (hiérarchie de classe, héritage, extension, masquage) et sera illustré par un exemple de représentation de

Plus en détail

CONCLUSIONS. Par rapport aux résultats obtenus, on peut conclure les idées suivantes :

CONCLUSIONS. Par rapport aux résultats obtenus, on peut conclure les idées suivantes : CONCLUSIONS L application de la PNL à l entreprise est confrontée aux besoins des leaders d équipe, tels que: la gestion de son propre développement, du stress, la résolution des problèmes tels que les

Plus en détail

Le raisonnement par récurrence

Le raisonnement par récurrence Le raisonnement par récurrence Nous notons N l ensemble des entiers naturels : N = {0,,, } Nous dirons naturel au lieu de entier naturel Le principe du raisonnement par récurrence Soit A une partie de

Plus en détail

CHAPITRE 4 FORMES NORMALES SYSTEMES COMPLETS DE CONNECTEURS 1

CHAPITRE 4 FORMES NORMALES SYSTEMES COMPLETS DE CONNECTEURS 1 Université Paris 7 U3MI36 CHAPITRE 4 FORMES NORMALES SYSTEMES COMPLETS DE CONNECTEURS 1 4.1 Formes normales Définitions : 1) Une formule F est sous forme normale disjonctive si et seulement si il existe

Plus en détail

Règles d affaires. éponse informatique inc. www.reponse.ca. Critères de qualité de toutes spécifications

Règles d affaires. éponse informatique inc. www.reponse.ca. Critères de qualité de toutes spécifications Règles d affaires éponse informatique inc. 1 Critères de qualité de toutes spécifications IEEE830-1998 Recommended Practice for Software Requirements Specifications Une spécification doit être: Correcte,

Plus en détail

ITIL, une approche qualité pour la gestion des services(*) informatiques. Pourquoi et comment introduire ITIL dans son organisation

ITIL, une approche qualité pour la gestion des services(*) informatiques. Pourquoi et comment introduire ITIL dans son organisation Livre blanc Le pragmatisme de votre système d information Rédacteur : Marc LORSCHEIDER / Expert ITIL Mise à jour : 05/06/2013 ITIL, une approche qualité pour la gestion des services(*) informatiques Pourquoi

Plus en détail

Logiciel Libre Cours 3 Fondements: Génie Logiciel

Logiciel Libre Cours 3 Fondements: Génie Logiciel Logiciel Libre Cours 3 Fondements: Génie Logiciel Stefano Zacchiroli zack@pps.univ-paris-diderot.fr Laboratoire PPS, Université Paris Diderot 2013 2014 URL http://upsilon.cc/zack/teaching/1314/freesoftware/

Plus en détail

Algorithmique et Analyse d Algorithmes

Algorithmique et Analyse d Algorithmes Algorithmique et Analyse d Algorithmes L3 Info Cours 5 : Structures de données linéaires Benjamin Wack 2015-2016 1 / 37 La dernière fois Logique de Hoare Dichotomie Aujourd hui Type Abstrait de Données

Plus en détail

Programme Luminy 2014!

Programme Luminy 2014! Programme Luminy 2014 Lundi 21 Avril Lundi 10h45 Richard Lassaigne Université Paris Diderot Introduction à la théorie de la complexité. Lundi 14h Thierry Dumont Math-Info Paris 10 Utilisation de logiciels

Plus en détail

Dynamic Computing Services solution de backup. White Paper Stefan Ruckstuhl

Dynamic Computing Services solution de backup. White Paper Stefan Ruckstuhl Dynamic Computing Services solution de backup White Paper Stefan Ruckstuhl Résumé pour les décideurs Contenu de ce White Paper Description de solutions de backup faciles à réaliser pour des serveurs virtuels

Plus en détail

SYSTEMES D INFORMATION & CONCEPTION de BdD

SYSTEMES D INFORMATION & CONCEPTION de BdD SYSTEMES D INFORMATION & CONCEPTION de BdD PLAN CONCEPT DE SYSTEME D INFORMATION MODELISATION D UN SYSTEME D INFORMATION MODELISATION CONCEPTUELLE : les METHODES METHODE SYSTEMIQUE METHODE OBJET L3 Informatique

Plus en détail

Cours de Génie Logiciel. David Janiszek. Le projet. En résumé. Troisième partie III. Eléments de gestion de projet

Cours de Génie Logiciel. David Janiszek. Le projet. En résumé. Troisième partie III. Eléments de gestion de projet Troisième partie III Eléments de gestion de projet Un projet informatique est l ensemble des activités et des actions à entreprendre pour répondre au besoin d informatisation d un ensemble de tâches dans

Plus en détail

Adaptation sémantique de documents SMIL

Adaptation sémantique de documents SMIL Adaptation sémantique de documents SMIL Sébastien Laborie Jérôme Euzenat Nabil Layaïda INRIA Rhône-Alpes - 655 Avenue de l Europe - 38334 St Ismier Cedex {Sebastien.Laborie;Jerome.Euzenat;Nabil.Layaida}@inrialpes.fr

Plus en détail

Représentation des nombres entiers et réels. en binaire en mémoire

Représentation des nombres entiers et réels. en binaire en mémoire L3 Mag1 Phys. fond., cours C 15-16 Rep. des nbs. en binaire 25-09-05 23 :06 :02 page 1 1 Nombres entiers 1.1 Représentation binaire Représentation des nombres entiers et réels Tout entier positif n peut

Plus en détail

Chapitre 2 : Conception de base de données relationnelle

Chapitre 2 : Conception de base de données relationnelle Chapitre 2 : Conception de base de données relationnelle Le modèle entité-association 1. Les concepts de base 1.1 Introduction Avant que la base de données ne prenne une forme utilisable par le SGBD il

Plus en détail

<< Crédit Club Auto >>

<< Crédit Club Auto >> Abbas Ahmad Année 2010/2011 Matin Bayramov Analyse et Modélisation des Systèmes Informatique (AMSI) Projet de Modélisation UML > Professeur encadrant : M. GUILLAUME PAQUETTE Projet

Plus en détail

Langages de programmation: approche scientifique

Langages de programmation: approche scientifique IGE 2004 - ENS 29 juin 2004 Présentation au CGTI 1 Informatique théorique 2 3 Une science? Informatique théorique Chaque science repose un dogme fondamental. Les mathématiques Les raisonnements formels

Plus en détail

Chapitre 2. Eléments pour comprendre un énoncé

Chapitre 2. Eléments pour comprendre un énoncé Chapitre 2 Eléments pour comprendre un énoncé Ce chapitre est consacré à la compréhension d un énoncé. Pour démontrer un énoncé donné, il faut se reporter au chapitre suivant. Les tables de vérité données

Plus en détail

Introduction. Chapitre 1. 1.1 Introduction. 1.1.1 Bibliothèques. 1.1.2 Programmation de Haute Qualité

Introduction. Chapitre 1. 1.1 Introduction. 1.1.1 Bibliothèques. 1.1.2 Programmation de Haute Qualité Chapitre 1 Introduction Buts du chapitre : Motivation pour l étude des types abstraits de données ; Syntaxe de base pour l écriture de spécifications. 1.1 Introduction 1.1.1 Bibliothèques 1. L3, déjà une

Plus en détail

Fondements de l informatique: Examen Durée: 3h

Fondements de l informatique: Examen Durée: 3h École polytechnique X2013 INF412 Fondements de l informatique Fondements de l informatique: Examen Durée: 3h Sujet proposé par Olivier Bournez Version 3 (corrigé) L énoncé comporte 4 parties (sections),

Plus en détail

FSAB 1402 - Suggestions de lecture

FSAB 1402 - Suggestions de lecture FSAB 1402 - Suggestions de lecture 2006 Concepts, techniques and models of computer programming Cours 1 - Intro Chapitre 1 (sections 1.1, 1.2, 1.3, pages 1-3) Introduction aux concepts de base Chapitre

Plus en détail

Théorie des Langages

Théorie des Langages Théorie des Langages Automates Claude Moulin Université de Technologie de Compiègne Printemps 2013 Sommaire 1 Automate fini 2 Automate et langages réguliers 3 Automate à pile Automate fini déterministe

Plus en détail

Les différents paradigmes de programmation

Les différents paradigmes de programmation Les différents paradigmes de programmation Un peu d histoire... Les problèmes posés par les s La programmation Un peu d histoire... Les difficultés du développement La programmation procédurale (ou impérative)

Plus en détail

Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation

Un peu d'organisation. Conception et Programmation par Objets HLIN406. Sommaire. Pourquoi vous parler de conception par objets? Notion de modélisation Un peu d'organisation Conception et Programmation par Objets HLIN406 Marianne Huchard, Clémentine Nebut LIRMM / Université de Montpellier 2 Premières semaines Contrôle des connaissances Supports 2015 Sommaire

Plus en détail

Environnements de Développement

Environnements de Développement Institut Supérieur des Etudes Technologiques de Mahdia Unité d Enseignement: Environnements de Développement Mme BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

Supplément théorique Inférence dans les réseaux bayésiens. Rappel théorique. Les processus aléatoires. Les réseaux bayésiens

Supplément théorique Inférence dans les réseaux bayésiens. Rappel théorique. Les processus aléatoires. Les réseaux bayésiens DÉPARTEMENT DE GÉNIE LOGICIEL ET DES TI LOG770 - SYSTÈMES INTELLIGENTS ÉTÉ 2011 Supplément théorique Inférence dans les réseaux bayésiens Rappel théorique Les processus aléatoires La plupart des processus

Plus en détail