FR2847360A1 - Procede et dispositif d'analyse de la securite d'un systeme d'information - Google Patents
Procede et dispositif d'analyse de la securite d'un systeme d'information Download PDFInfo
- Publication number
- FR2847360A1 FR2847360A1 FR0214279A FR0214279A FR2847360A1 FR 2847360 A1 FR2847360 A1 FR 2847360A1 FR 0214279 A FR0214279 A FR 0214279A FR 0214279 A FR0214279 A FR 0214279A FR 2847360 A1 FR2847360 A1 FR 2847360A1
- Authority
- FR
- France
- Prior art keywords
- component
- attack
- components
- attacks
- rules
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 65
- 238000004088 simulation Methods 0.000 claims abstract description 29
- 238000011144 upstream manufacturing Methods 0.000 claims description 31
- 230000004224 protection Effects 0.000 claims description 19
- 230000008569 process Effects 0.000 claims description 18
- 238000001514 detection method Methods 0.000 claims description 13
- 230000000694 effects Effects 0.000 claims description 7
- 230000006870 function Effects 0.000 claims description 7
- 238000010521 absorption reaction Methods 0.000 claims description 6
- 230000009471 action Effects 0.000 claims description 5
- 239000013598 vector Substances 0.000 claims description 5
- 230000002457 bidirectional effect Effects 0.000 claims description 2
- 238000004364 calculation method Methods 0.000 claims 1
- 230000001771 impaired effect Effects 0.000 claims 1
- 230000002452 interceptive effect Effects 0.000 abstract description 5
- 238000010586 diagram Methods 0.000 description 35
- 230000007246 mechanism Effects 0.000 description 14
- 239000002253 acid Substances 0.000 description 9
- 230000015654 memory Effects 0.000 description 7
- 230000006399 behavior Effects 0.000 description 6
- 238000013459 approach Methods 0.000 description 5
- 238000012360 testing method Methods 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 4
- 230000007123 defense Effects 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 238000013475 authorization Methods 0.000 description 3
- 230000015556 catabolic process Effects 0.000 description 3
- 238000010276 construction Methods 0.000 description 3
- 238000006731 degradation reaction Methods 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 230000000670 limiting effect Effects 0.000 description 3
- 239000011159 matrix material Substances 0.000 description 3
- 230000002265 prevention Effects 0.000 description 3
- 241000272201 Columbiformes Species 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 2
- 230000006378 damage Effects 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 238000004880 explosion Methods 0.000 description 2
- 230000036961 partial effect Effects 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 229920006395 saturated elastomer Polymers 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 241000700605 Viruses Species 0.000 description 1
- 230000004308 accommodation Effects 0.000 description 1
- WYTGDNHDOZPMIW-RCBQFDQVSA-N alstonine Natural products C1=CC2=C3C=CC=CC3=NC2=C2N1C[C@H]1[C@H](C)OC=C(C(=O)OC)[C@H]1C2 WYTGDNHDOZPMIW-RCBQFDQVSA-N 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000001066 destructive effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000004438 eyesight Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000007429 general method Methods 0.000 description 1
- 230000005484 gravity Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000012804 iterative process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000012502 risk assessment Methods 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1433—Vulnerability analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/577—Assessing vulnerabilities and evaluating computer system security
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/20—Design optimisation, verification or simulation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2111/00—Details relating to CAD techniques
- G06F2111/08—Probabilistic or stochastic CAD
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computing Systems (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Evolutionary Computation (AREA)
- Geometry (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
Un procédé d'analyse de la sécurité d'un système d'information comporte une phase de modélisation (1,2), comprenant la modélisation du système d'information, et une phase de simulation, comprenant la spécification (3) et la simulation (4) d'attaques potentielles contre le système d'information.
Description
PROCEDE ET DISPOSITIF D'ANALYSE DE LA SECURITE D'UN SYSTEME
D'INFORMATION
La présente invention se rapporte au domaine des outils d'analyse et
de maîtrise de la sécurité des systèmes d'information (SSI).
Les outils de conception structurée d'un système d'information (tels que SADT ou SART) ne prennent pas en compte la sécurité du système. Les méthodes généralistes d'analyse du risque (telles que Marion, Melisa, ou CRAMM) sont peu précises, et incapables de mettre en évidence les failles techniques d'un système. Les outils de sreté de fonctionnement (SDF) sont limités aux problèmes de fiabilité et de disponibilité, mais ne prennent pas en compte la malveillance. Les systèmes de détection d'intrusion (IDS pour "Intrusion Detection Systems") et les analyseurs de vulnérabilité ne fonctionnent que sur des systèmes réels, sont spécifiques d'un domaine restreint, et n'ont qu'une vision partielle de la sécurité. Les éditeurs de stratégie de sécurité fonctionnent selon le point de vue du défenseur seulement, et ne comportent pas de fonction d'analyse de la cohérence de la sécurité, ni de
recherche des failles et des attaques possibles.
L'invention a pour objet un procédé et un dispositif d'analyse de la sécurité des systèmes d'information qui repose sur la modélisation et la simulation du système et des attaques possibles, pour analyser et maîtriser la
sécurité du système.
Plus particulièrement, un premier aspect de l'invention concerne un procédé d'analyse de la sécurité d'un système d'information comprenant: une phase de modélisation comprenant la modélisation du système d'information; et, - une phase de simulation, comprenant la spécification et la simulation
d'attaques potentielles contre le système d'information.
La phase de modélisation comprend la spécification de l'architecture du système avec un ensemble de composants du système et des relations entre lesdits composants, c'est-à-dire suivant un modèle
composants / relations.
De préférence, des états déterminés sont associés à chaque composant du système d'information, chaque état pouvant prendre une valeur saine et une ou plusieurs valeurs non saines. Certains au moins desdits états se rapportent respectivement à l'activité, à la confidentialité, à l'intégrité et/ou à
la disponibilité du composant auquel ils sont associés.
De préférence, la phase de modélisation comprend en outre la spécification d'un ensemble de règles de comportement, notamment au plan du fonctionnement du système et au plan de la sécurité (règles de protection),
associées aux composants du système.
Selon un avantage de l'invention, l'utilisateur peut adopter le point de vue du défenseur pendant la phase de modélisation, et le point de vue de l'attaquant pendant la phase de simulation. En itérant des phases de modélisation et des phases de simulation alternées, il parvient à maîtriser la
sécurité du système d'information.
Selon un autre avantage, l'invention permet d'analyser la sécurité d'un système d'information sans intervention directe sur celui-ci. En effet, le lancement des attaques se fait sur un système virtuel, correspondant au
système réel modélisé.
Avantageusement, l'analyse de la sécurité peut avoir lieu très tôt dans le processus de conception du système d'information, et notamment avant son
déploiement physique.
Le procédé permet de modéliser un système d'information, en se limitant à ses aspects sécurité, et donc en restant maîtrisable par une personne humaine, grâce à des concepts et principes simplificateurs. L'invention permet de traiter d'une façon générique les aspects notamment techniques (c'est-àdire liés aux caractéristiques techniques du système d'information), humains, procéduraux et physiques (par exemple géographiques). Un bon compromis entre réalisme et simplicité de la modélisation permet à un utilisateur (typiquement le concepteur ou l'administrateur du système d'information, ou un auditeur technique de la sécurité) de modéliser le système d'information sans
avoir à le reproduire complètement.
Le procédé permet aussi de simuler avec réalisme toutes les attaques connues dans le monde des systèmes d'information. Ces attaques s'avèrent génériques, et peuvent s'appliquer aux domaines connexes des systèmes
d'information (sécurité physique par exemple).
Il permet enfin de simuler avec réalisme toutes les parades connues dans le monde des systèmes d'information, qu'elles soient de prévention ou de détection. La modélisation des parades de prévention est réalisée par des règles de sécurité. La modélisation des parades de détection est réalisée au moyen de métriques. En résumé, le procédé permet d'analyser en peu de temps la faisabilité d'un très grand nombre d'attaques sur un système donné. Avec un peu d'expérience, l'utilisateur peut simuler environ 100 à 200 attaques élémentaires par jour, ce qui est considérablement plus que ce qu'on pourrait faire sur un
système réel.
Un second aspect de l'invention concerne un dispositif pour la mise en oeuvre d'un procédé selon le premier aspect. A cet effet, le dispositif comprend avantageusement une interface Homme / machine pour la mise en oeuvre de la phase de modélisation et/ou un moteur attaques / parades pour la mise en oeuvre de la phase de simulation Avantageusement, l'interface Homme / machine présente une
fonctionnalité d'affichage en multi vues du système modélisé.
De préférence, l'interface Homme / machine permet d'afficher le
système modélisé selon un modèle composants / relations.
Le dispositif est destiné à être utilisé en tant qu'outil d'audit technique de la sécurité des systèmes d'information existants (c'est-àdire déjà déployés), pour lesquels il présente l'avantage de ne pas les perturber pendant leur exploitation. Il peut notamment analyser des attaques destructrices sans
affecter le système réel.
Le dispositif peut aussi être utilisé en tant qu'outil d'aide à la conception de la sécurité de systèmes en cours de conception ou de réalisation, ce qui permet la mise au point et le test de leur politique de protection avant même
leur installation.
Il peut aussi être utilisé en tant qu'outil privilégié de certification de système, au sens de la certification sécurité selon la normalisation existante: TCSEC, ITSEC ("Information Technology Security Evaluation Criteria") et CC ("Common Criteria"). Cette normalisation permet en effet actuellement de certifier des produits aux contours nettement délimités, mais est jusqu'à maintenant inapplicable aux systèmes. Ces derniers sont en effet trop vastes, complexes, hétérogènes, aux contours mal définis et évolutifs, pour être
évalués avec les techniques d'évaluation de produits.
En résumé, le dispositif est un outil destiné à des spécialistes de la sécurité: administrateurs système, auditeurs techniques de la sécurité. A ces personnes, il apporte en plus la possibilité d'adopter le point de vue de l'attaquant, point de vue absolument nécessaire pour construire une protection
efficace et adaptée.
D'autres caractéristiques et avantages de l'invention apparaîtront
encore à la lecture de la description qui va suivre. Celle-ci est purement
illustrative et doit être lue en regard des dessins annexés sur lesquels: - la figure 1 est un diagramme illustrant les phases de modélisation et de simulation selon le procédé de l'invention; - la figure 2 est un schéma synoptique illustrant les éléments d'un dispositif selon l'invention; - la figure 3 est un schéma illustrant la construction d'un modèle composants / relations pour un système d'information; - la figure 4 est un schéma montrant un exemple de modèle composants / relations, sur lequel apparaissent des relations d'hébergement et des relations d'échange entre des composants; - la figure 5 est un schéma illustrant des exemples de relations de service entre des composants d'un système d'information modélisé selon l'invention; - la figure 6 est un schéma qui illustre un exemple détaillé de la phase de simulation du procédé selon l'invention les figures 7a à 7e sont des schémas qui illustrent des exemples de chemins d'attaque; - la figure 8 est un schéma montrant la transmission d'une attaque à travers un chemin d'attaque dans un système d'information modélisé; - la figure 9 et la figure 10 sont des schémas présentant un mécanisme de piles amont et aval; - la figure 11 est un schéma illustrant un exemple de fonctionnement des piles amont et aval; - la figure 12 est un diagramme illustrant l'algorithme général de fonctionnement du moteur attaques / parades; - la figure 13 est un diagramme qui illustre un mécanisme d'application des règles de protection; - les figures 14a et 14b sont des diagrammes illustrant un mécanisme de routage fonctionnel et un mécanisme de contagion d'états, respectivement; - la figure 15 est un schéma illustrant des techniques de détournement dans un système d'information modélisé; - la figure 16 est un schéma illustrant l'affichage d'un système modélisé, avec une fonctionnalité multi-vues; la figure 17 est schéma illustrant l'affichage multi vues selon une approche hiérarchique; et,
- la figure 18 est un schéma synoptique d'un dispositif selon l'invention.
Comme illustré par le graphe de la figure 1, le procédé comporte deux
phases d'utilisation, elles même décomposées en deux étapes.
Pendant une phase de modélisation, l'utilisateur adopte le point de vue du défenseur. La phase de modélisation comprend une étape 1 de spécification de l'architecture du système avec un ensemble de composants du système et des relations entre lesdits composants, qui comprennent des relations de propagation et des relations de service. L'étape 1 aboutit à l'architecture modélisée du système réel, appelée modèle composants / relations dans la suite, ce modèle étant sauvegardé sous la forme d'un fichier dans une mémoire 11. Ce modèle peut être représenté de façon graphique par un graphe comportant des boîtes symbolisant les composants, reliées par des flèches symbolisant les relations. La phase de modélisation comprend aussi une étape 2 de spécification de règles de comportement, à ne pas confondre avec les relations précitées. Ces règles de comportement définissent le fonctionnement de chaque composant, aux plans
du fonctionnement et de la sécurité, en particulier les protections qu'il assure.
L'étape 2 aboutit à la construction d'un fichier de règles de comportement, qui
est sauvegardé dans une mémoire 12.
A l'inverse, pendant une phase de simulation, l'utilisateur adopte le point de vue de l'attaquant. La phase de simulation comprend une étape 3 de spécification des attaques, qui aboutit à la création d'un ou plusieurs scénarios d'attaques. Ces scénarios sont sauvegardés sous la forme de fichiers dans une mémoire 13. La phase de simulation comprend aussi une étape 4 de simulation interactive d'attaques. Cette simulation est réalisée par un moteur attaques / parades. Elle aboutit à la création d'un journal des attaques, qui est
sauvegardé sous la forme d'un fichier dans une mémoire 14.
Les fichiers sauvegardés dans les mémoires 11, 12, 13 et 14 peuvent être importés de ou exportés vers différentes applications, en sorte que leur
réutilisation est possible.
Les phases de modélisation 10 et de simulation 20 peuvent être itérées de façon alternée, en modifiant à chaque fois tout ou partie des paramètres (modèle composants/ relations, règles de comportement, attaques) pris en compte. Ceci permet une bonne maîtrise de la sécurité du système par l'utilisateur.
Dans la suite de la description, il est décrit un mode de mise en oeuvre
des étapes 1 à 4 du procédé, avec toutefois une présentation modifiée quant à l'ordre des étapes. En effet, l'étape 3 (spécification d'attaques) et l'étape 4 (simulation interactive par moteur attaques / parades) sont exposées avant l'étape 2 (paramétrage des règles de protection), pour aider à la
compréhension du texte. En outre, la description de ces étapes est complétée
par une présentation de deux mécanismes complémentaires: les métriques et
l'interface Homme / machine (IHM).
Au préalable, les principaux éléments d'un dispositif selon l'invention sont présentés en référence au diagramme fonctionnel de la figure 2. Sur cette figure, on a représenté en partie haute un groupe 20a des éléments utilisés pendant la phase de modélisation, et en partie basse un groupe 20b de ceux utilisés pendant la phase de simulation. De plus, une interface
Homme / machine 15 est représentée sur la droite.
Le groupe 20a comprend un langage de règles 21 permettant d'élaborer les règles de protection 22, un ensemble de métriques de base 23,
et le modèle composants / relations 24.
Le groupe 20b comprend un langage d'attaques 25 permettant d'élaborer les scénarios d'attaques 26, le moteur attaques/ parades 16, un mécanisme de piles amont et aval 27, un ensemble d'états potentiels 28 et des
métriques calculées 29.
A la figure 2, les flèches en traits continus symbolisent les transferts d'informations entre les éléments, et les traits discontinus symbolisent les liens fonctionnels entre les éléments. Le rôle de chacun de ces éléments apparaîtra
dans ce qui suit.
La première étape du procédé, étape 1, consiste à construire le modèle composants / relations (ou architecture) du système réel via l'interface humaine 15. Pour cela, le système est décomposé en composants élémentaires (ou
atomes), dotés d'attributs, et reliés par des relations.
Les étapes de la construction du modèle composants / relations sont
illustrés par le graphe de la figure 3.
Une première étape 31, l'utilisateur met en place sur un graphe à deux dimensions les composants qui forment le système. Dans un exemple, chaque composant est représenté par un rectangle contenant ses quatre états
potentiels et son nom.
Les composants peuvent représenter toutes sortes d'objets réels hétérogènes de type physique (site, bâtiment, étage, local, bureaux coffre, porte, fenêtre, serrure, clé,...), support (papier, disque fixe, disquette, CDROM, bande magnétique,...), réseau (électrique, informatique, téléphonique, hertzien, aérien,...), matériel (mécanique, réseau, informatique, poste, serveur, écran, clavier, imprimante,...), logiciel (OS, driver, application, service,...), données (répertoire, fichier, information, base de données, mot de passe,...), personnes (utilisateur, agresseur, directeur, administrateur, organisation, service,...), etc.
Cette liste indicative est non limitative.
Chaque composant a plusieurs attributs, qui sont définis dans une étape 32. Les attributs comprennent des attributs statiques et des attributs dynamiques. Les attributs statiques comprennent par exemple un nom (composé d'une nature et d'un identifiant), et éventuellement un ou plusieurs adjectifs. Les attributs dynamiques comprennent par exemple des états potentiels dits états "ACID" (voir plus loin), un nom prétendu (dans le cas o le composant est usurpateur), et un lien vers un composant usurpateur (dans le
cas o le composant est usurpé).
Les adjectifs ont pour but de permettre de désigner des composants sans les nommer, et ceci soit dans des règles (par exemple: tous les composants "externes" sont interdits d'accès), soit dans des attaques (par exemple: découvrir tous les composants "IP"). La liste des adjectifs est ouverte, et définie par l'utilisateur lors de la modélisation. Un exemple d'adjectifs classés par utilité est donné par la tableau I ci- dessous: utilité adjectifs appartenance interne, externe, privé, public, établissement, groupe, l__________________ central, local, distant sensibilité, gravité normal, important, critique, vital, droits réservés (DR), confidentiel défense (CD), secret défense (SD), topsecret défense (TSD), tactique, stratégique droit d'accès, rôle usager, rédacteur, lecteur, éditeur, technicien, opérateur, technique ou exploitant, administrateur, stagiaire, employé, gardien, organisationnel, surveillant, responsable, gestionnaire, directeur, client, interne ou externe partenaire, consultant, fournisseur, client, concurrent confiance ou fiable, fidèle, sincère, sérieux, connu, inconnu, douteux, méfiance suspect, pirate technique IP, réseau, informatique, OS, exécutable, information,
fixe, mobile.
protection crypté, caché, secouru, répertorié, administré, dupliqué
Tableau I
La modélisation est une tâche complexe pour l'utilisateur. C'est pourquoi les mécanismes de modélisation sont conçus pour fonctionner même sur un modèle non complètement terminé, donc éventuellement partiellement incohérent. Ceci permet à l'utilisateur de travailler selon un processus progressif et itératif, alternant la modélisation et les tests de fonctionnement par
simulation.
Les composants sont ubiquistes et intemporels. Ce principe a pour but de simplifier le travail de modélisation, sans nuire au réalisme, dans la mesure o le thème est la sécurité. Il se traduit concrètement par le fait qu'un composant peut être, notamment: - multiple, c'est-à-dire représenter plusieurs objets réels semblables situés en plusieurs endroits; dispersé, c'est-à-dire représenter un objet de grande taille non situé dans une zone précise (par exemple un réseau); - partiel, c'est- à-dire représenter une partie d'un objet réel complexe; - répliqué, lorsque deux composants peuvent représenter le même objet réel (par commodité de modélisation); - dupliqué, lorsque, par exemple, un même fichier réel présente plusieurs copies sur plusieurs supports; - temporaire, c'est-à-dire représenter par exemple une communication téléphonique intermittente; et - mobile: par exemple, un poste portable, ou une personne sont
mobiles ("nomades") par nature.
Dans une étape 33, ont définit des relations de propagation associées aux composants. Ces relations sont bidirectionnelles, et susceptibles de véhiculer des attaques dans les deux sens. Elles peuvent être de deux types
distincts: de type hébergement (contenance, alimentation) et de type échange.
Le schéma de la figure 4 illustre un exemple de relations d'hébergement (symbolisées par des flèches verticales) entre un logiciel client 41, un poste de travail 42 (un ordinateur personnel ou PC) dans lequel ledit logiciel client est sauvegardé, et un bureau 43 dans lequel ledit poste de travail est situé. Le même schéma illustre aussi des relations d'échange entre le logiciel client 41 et un logiciel serveur 44 avec lequel le logiciel client échange des données, entre le poste de travail 42 et un réseau informatique auquel le poste de travail est raccordé 45, et entre le bureau 43 et un couloir 46
permettant l'accès audit bureau.
Quand un composant est traversé par une attaque, il peut ou non laisser une trace du passage dans l'attaque. Par exemple, un paquet postal porte le cachet du bureau de poste émetteur, mais pas du bureau de poste récepteur. De même, un paquet IP ("Internet Protocol") contient ou non
l'adresse IP d'un routeur traversé.
Pour prendre en compte cette réalité, chaque composant, pour
chacune des relations qu'il reçoit, a un indicateur de transparence ou opacité.
S'il est transparent, il ne sera pas vu des composants avals sur le chemin de l'attaque, et ces composants ne pourront donc pas en tenir compte dans leurs règles de protection. Si au contraire il est opaque, les composants avals le verront, mais il cachera les composants amonts de même type (c'est à dire
ayant les mêmes adjectifs).
A côté des relations de propagation, on prévoit aussi des relations de service, qui sont définies dans une étape 34. Les relations de service sont unidirectionnelles, et ne véhiculent pas d'attaques. Elles ont pour but de permettre de désigner un composant à partir d'un autre, sous la forme d'une indexation. Le schéma de la figure 5 illustre un exemple de relation de service. Sur cette figure, on a représenté un poste de travail 51, une personne 52, un mot de passe 53 et un bureau 54. Des relations de propagation entre ces composants sont symbolisées par des traits continus, et des relations de service sont symbolisées par des traits discontinus le composant. Dans cet exemple, le composant "mot de passe" 53 peut être désigné par la formule "passe(personne)". De même, le composant "bureau B24" peut être désigné
par "bureau(personne)".
De retour à la figure 3, on notera que les étapes 31 à 34 peuvent être itérées pour permettre à l'utilisateur d'affiner la construction du modèle
composants / relations.
Quand le modèle composants / relations est terminé, une table de routage est construite dans une étape 35. Cette table est calculée automatiquement selon le principe du plus court chemin entre les composants, en utilisant les relations de propagation uniquement. Le résultat est par
exemple une matrice composant de départ / composant d'arrivée.
L'évolution dans le temps de chaque composant est mémorisée au moyen de quatre états potentiels, appelés états "ACID" (A = activité, C = confidentialité, I = intégrité, D = disponibilité). Ces états correspondent aux trois domaines connus de la sécurité (C, 1, D), auxquels a été ajouté l'état "A" pour "activité". Ce dernier état représente la capacité d'un composant à agir, soit de façon normale (licite), soit de façon malveillante, et ceci sous l'influence
de l'agresseur.
On pourra noter que ces états ACID correspondent sensiblement aux droits élémentaires des modèles de sécurité: "XRWD" (X = execute, R = read,
W = write, D = delete). Ils sont indépendants les uns des autres.
Dans un exemple chaque état a quatre valeurs possibles: normal, affaibli, dégradé, dangereux. Dans un exemple, ces valeurs sont codées sur le graphe composants I relations par un code de couleur (par exemple vert, jaune, rouge, bleu foncé, respectivement), utilisé pour le remplissage du
rectangle symbolisant chaque composant.
Le tableau Il ci-dessous donne la signification des quatre valeurs
possibles des quatre états ACID potentiels.
Etats ACID: Activité Confidentialité Intégrité Disponibilité sain fermé discret intègre disponible affaibli ouvert découvert usurpateur saturé dégradé actif divulgué altéré bloqué dangereux interactif trahi corrompu détruit
Tableau Il
Le but de l'analyse est d'étudier la possibilité de réaliser une intrusion dans un système. Dans la mesure o il est nécessaire de faire des simplifications par rapport à la réalité, il est préférable de simplifier dans le sens du pessimisme, ceci dans un but sécuritaire. En d'autres termes, le dispositif peut voir des intrusions là o il n'y en n'a pas, mais ne doit pas oublier des intrusions réellement possibles. L'utilisateur fera ensuite la part des choses, si
nécessaire.
Ce principe, dit de la "politique du pire" est appliqué dans le moteur
attaques / parades de la manière suivante.
Au départ de la modélisation, les quatre états potentiels de chaque composant sont respectivement initialisés à la valeur "sain". L'utilisateur peut les initialiser manuellement à une valeur différente s'il le souhaite. Les états ne peuvent ensuite évoluer que vers la dégradation, au fur et à mesure des
attaques réussies.
Les états sont "potentiels", c'est-à-dire qu'ils signifient que les
composants "peuvent" se trouver dans les états indiqués, mais pas forcément.
Ceci implique que deux états apparemment incompatibles (par exemple, un composant à la fois "actif" et "détruit") peuvent coexister. Quand deux états sont incompatibles ou incohérents, le dispositif choisit la situation la plus
défavorable au défenseur.
Quand un composant (modélisé) représente plusieurs objets réels, ses
états potentiels sont ceux de l'objet réel le plus dégradé.
Enfin, le test d'un état de composant dans une règle ne correspond pas à une relation d'égalité, mais à une relation d'ordre. Par exemple, le test
"composant = bloqué" est positif si le composant est soit "bloqué", soit "détruit".
On va maintenant décrire un exemple de mise en oeuvre de l'étape 3 et de l'étape 4 du procédé, à savoir la spécification des scénarios d'attaque et leur simulation interactive. A cet effet, il est fait référence au diagramme de la figure 6. Dans une étape 61, une attaque est définie. Dans un exemple, il est prévu une attaque pour chaque dégradation d'un état ACID. Les attaques correspondantes sont appelées attaques élémentaires dans la suite. Elles sont liées directement aux états ACID. Par exemple, pour faire passer un
composant à l'état "bloqué", on utilise l'attaque "bloquer".
Il y a donc douze attaques élémentaires (correspondant aux douze valeurs d'états potentiels non saines), qui sont résumées dans le tableau 1I1 cidessous, plus une attaque spéciale dite attaque d'usurpation. Cette dernière attaque, appelée "ChangerNomPrétendu", permet à un composant d'usurper le nom d'un autre. L'usurpation est en effet une technique fondamentale de l'intrusion. attaques Activité Confidentialité Intégrité Disponibilité
A C ID _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
faible ouvrir découvrir usurper saturer grave activer espionner altérer bloquer dangereuse pénétrer trahir corrompre détruire
Tableau l
Lors de la définition d'une attaque élémentaire, l'utilisateur (qui se place du point de vue de l'attaquant) saisit les paramètres suivants: type d'attaque, parmi les 13 ci dessus; - type de protocole (voir ci dessous); et,
- éléments du chemin (voir plus loin).
Le "protocole" généralise le concept de protocole de télécommunication, et désigne tout moyen de transmission d'une attaque entre deux composants. Une attaque se concrétise toujours par la transmission dans le système d'un objet réel, physique ou logique, véhiculant des informations,
des logiciels ou des mécanismes malveillants.
La liste des protocoles est ouverte, l'utilisateur pouvant en définir autant qu'il souhaite lors de la modélisation. Des exemples de protocoles sont:
- protocoles physiques: lettre, colis, disquette, CDROM, personne,...
- protocoles logiques et informatiques: mail, web, fichier, Teinet,
Netbios, TCP/IP, FTP, SSL,...
- protocoles spécialisés: missile, onde hertzienne, laser,...
- etc. Le langage d'attaque utilise les mêmes mots que le langage de règles, et permet de définir des scénarios d'attaques complexes. Une ligne d'attaque élémentaire est par exemple: "départ=agresseur + intermédiaire=lnternet + protocole=mail + arrivée=usager + attaque=détruire + cible=poste(usager)" En français, cette ligne d'attaque signifie que l'agresseur envoie, via Internet, un courrier électronique à l'usager, contenant une bombe logique qui va
détruire son poste.
Le chemin d'attaque est l'un des concepts centraux du dispositif, dont l'objet est justement de trouver des chemins d'attaque dans un système modélisé. Lors de la simulation, l'utilisateur spécifie le chemin sous la forme suivante: - un composant de départ; - un composant d'arrivée; - un composant cible; et, éventuellement
- un composant intermédiaire.
L'agresseur et la cible doivent nécessairement se trouver sur le chemin,mais pas nécessairement au début ou à la fin. Le schéma des figures 7a à 7e montrent diverses possibilités (non limitatives) de chemin d'attaque, qui peuvent correspondre chacune à un cas réel. Par exemple, lorsque la cible est un poste de travail: - à la figure 7a, l'agresseur sature le poste de travail par du trafic artificiel transmis via le réseau; - à la figure 7b, l'agresseur envoie un virus par courrier électronique qui est exécuté par un usager "pigeon", ce qui altère le poste de travail; - à la figure 7c, l'agresseur est un serveur pirate, et c'est un usager "pigeon" qui consulte une page web sur serveur pirate et reçoit un applet Java pirate qui altère le poste; - à la figure 7d, l'agresseur est aussi un serveur pirate et le poste de travail (rendu actif) ouvre une "reverse back door" vers le serveur pirate; et, - à la figure 7e, l'agresseur est un réseau altéré par lequel passe une
session, dévoilant ainsi des informations du poste de travail.
Bien entendu, les exemples ci-dessus sont illustratifs et nullement limitatifs. De retour à la figure 6, l'attaque spécifiée à l'étape 61 est lancée dans une étape 62. Dans une étape 63, elle est exécutée par le moteur d'attaques / parades. Et dans une dernière étape 64, le résultat de l'attaque est constaté. Les étapes 61 à 64 sont itérées, étant exécutées pour chaque
attaque du scénario d'attaques.
Le résultat d'une attaque, si elle réussit, est de faire passer l'un des états ACID du composant cible à une valeur dégradée (non saine), voire à une valeur dégradée plus grave si il était déjà à une valeur dégradée. Par exemple dans le cas de l'attaque "bloquer": - si le composant est moins dégradé que "bloqué" (par exemple, "saturé"), alors il devient "bloqué"; - s'il est déjà "bloqué", alors il reste "bloqué"; et, - s'il est plus dégradé que "bloqué" (par exemple "détruit"), alors il ne
change pas d'état.
On va maintenant décrire plus en détails le fonctionnement du moteur d'attaques / parades. Typiquement, la transmission d'une attaque sur le chemin d'attaque se fait selon trois phases successives, illustrées par le schéma de la figure 8, à savoir: - une phase de propagation durant laquelle l'attaque traverse les composants vecteurs, qui peuvent ou non assurer un filtrage de sécurité via leurs règles de protection; - une phase d'absorption durant laquelle l'attaque peut ou non dégrader la cible, selon ses défenses propres (règles de protection); et, - une phase de contagion durant laquelle la dégradation de la cible peut se communiquer à d'autres composants sans qu'ils puissent se défendre (par exemple, l'explosion d'un bureau entraîne la destruction des équipements
présents dans ce bureau).
Quand une attaque arrive dans un composant, le moteur attaques / parades effectue pour lui un certain nombre de contrôles (règles), basés sur les états de certains composants, et en particulier sur les composants situés en amont et en aval sur le chemin de l'attaque. Pour ces derniers, représentés sur le schéma de la figure 9, les informations dont dispose le moteur attaques / parades sont consignées respectivement dans la pile amont et dans la pile aval qui ont été présentées plus haut en regard du schéma de la figure 2. Ces piles amont et aval sont la modélisation des indications portées sur les objets réels (par exemple adresses et cachets de la
Poste sur un colis, adresses IP sur un paquet IP, etc.).
La pile amont donne la liste (dans l'ordre) de tous les composants déjà traversés par l'attaque. Dans un exemple, il y a précisément deux piles amont: l'une qui contient la liste exhaustive de tous les composants, avec leur nom réel, et l'autre qui contient uniquement la liste des composants opaques, avec leur nom prétendu. La première liste est utilisée pour exécuter les règles de possibilité et de contagion du composant. L'autre est utilisée pour exécuter
pour les règles de protection (identification, autorisation et routage).
La pile aval donne la liste des destinataires identifiés de l'attaque. Il y a un destinataire final, et éventuellement un ou plusieurs destinataires intermédiaires. Ces destinataires intermédiaires sont spécifiés, soit par l'utilisateur lors de la définition d'une attaque, soit par le routage fonctionnel. La
pile aval est utilisée par les règles des composants.
Dans l'exemple illustré à la figure 10, le routeur 111 et l'internet 112 sont transparents (car l'adresse IP source des paquets IP venant de l'extérieur est inchangée). C'est pourquoi, étant empilés dans la première pile amont 110 des noms réels, et ils ne sont pas empilés dans la seconde pile amont 120 des noms visibles (c'est-à-dire réel ou prétendu, le cas échéant). Par ailleurs, le pirate 113 usurpe le nom d'un usager 114. Son "nom visible" (empilé dans la seconde pile amont 120) est donc "usager" et non "pirate". La pile aval est
désignée par la référence 130.
Pour chaque transit d'une attaque, le moteur effectue les trois opérations suivantes: - premièrement, il détermine le prochain composant destinataire de l'attaque: c'est le premier composant de la pile aval, - deuxièmement, il détermine, grâce à la matrice de routage local, quelle est la relation à emprunter pour aller vers ce composant; et, - troisièmement, le composant qui se trouve de l'autre côté de la
relation devient le composant en cours.
L'attaque s'arrête quand la pile aval est vide (et non quand le composant d'arrivée est atteint, car d'autres composants peuvent être empilés
en aval après l'arrivée).
Pour le composant en cours (atteint par l'attaque), le moteur effectue les opérations suivantes, illustrées par le schéma de la figure 11: - il extrait le composant en cours de la pile aval, s'il y est (étape 1); - il teste les règles de propagation du composant, qui peuvent accepter ou refuser l'attaque; - si l'attaque est refusée, le moteur l'arrête, sinon il continue les actions suivantes, - dans le cadre des règles de routage fonctionnel, il peut empiler un composant intermédiaire en aval (étape 2); - il empile le composant en cours dans la pile amont (étape 3); et
- si l'attaque est acceptée, il la route vers le composant suivant.
L'algorithme général de fonctionnement du moteur d'attaques / parades
est donnée par le diagramme de la figure 12.
Sur ce diagramme, le mot-clé "moi" désigne le composant en cours.
Pour transporter ou absorber une attaque, le composant en cours doit être dans l'état "ouvert" (état A des états ACID). Pour absorber l'attaque, le composant cible doit se trouver dans la première pile amont, celle des noms réels. On notera que les règles d'identification et d'autorisation donnent
toujours "oui" pour résultat si le composant est corrompu.
A la figure 12, les trois phases de la transmission de l'attaque, à savoir la propagation, l'absorption et la contagion de l'attaque, sont représentées séparément. On va maintenant décrire l'étape 2 du procédé, qui est le paramétrage
des règles de protection des composants.
Lorsque l'architecture d'un système est spécifiée (à la fin de l'étape 1), cette architecture étant représentée par le graphe composants / relations, il reste en effet à décrire le comportement des composants, aux plans du
fonctionnement et de la sécurité.
A cet effet, l'étape 2 consiste à paramétrer le fonctionnement de chaque composant, et en particulier à décrire les protections qu'il assure. Ceci est fait au moyen de la saisie de règles, structurées selon un langage et une
grammaire de règles.
Le langage de règles se caractérise par, sa capacité au réalisme (pour décrire précisément le fonctionnement d'un composant réel), l'ergonomie pour l'usager (simplicité, souplesse, naturel, peu de signes spéciaux) et la généricité (c'est-à-dire le fait de permettre une réutilisation facile des règles d'un modèle à l'autre). Au plan de l'édition, le langage est de préférence sous forme de texte ASCII ou XML, est lisible, modifiable et imprimable avec un traitement de texte classique (tel que Notepad, MSOffice), accepte des commentaires en langage naturel sous la forme: /* commentaire */, accepte les majuscules I minuscules et accents (mais qui ne sont pas discriminants), et utilise les caractères "blanc"
et "ligne suivante" uniquement pour la présentation.
De préférence, les mots du langage apparaissent de la même façon et sous la même forme dans la représentation graphique du modèle composants / relations, dans la spécification des règles (langage de règles), dans la spécification des attaques (langage d'attaques), et dans le journal des attaques. Le langage est principalement un langage de prédicats (ou critères de condition logique), utilisant des opérateurs logiques (tels que ET, OU, NON), des mots-clés (tels que "attaque", "amont", "aval", "protocole", "moi"), et des noms de composants sous forme directe ou par adjectif, ou encore par relation
de service.
Par exemple, le prédicat "amont(person)=admin + attaque=corrompre" signifie que l'attaque "corrompre" est autorisée à passer dans le composant s'il
y a en amont une personne ayant rôle "admin" (administrateur).
Un exemple de mots-clés génériques, qui est illustratif seulement, est donné par le tableau IV ci-dessous. Par ailleurs, à ces mots clés génériques, il y a lieu d'ajouter les seize valeurs des états potentiels et les douze valeurs des attaques. mot-clé désigne signification utilisable par générique règles attaques amont composant en amont (règles possibilité et + contagion) amont composant en amont (autres règles) sous nom + prétendu aval composant en aval + moi composant en cours de traitement l entrée composant dernier traversé en amont ( l relation d'entrée) départ composant premier en amont + + cible composant cible de l'attaque + + arrivée composant point d'arrivée de l'attaque + + attaque attaque type d'une attaque + + protocole protocole type de protocole + + intermédiaire composant imposé sur le chemin de l'attaque + estlicite mode indique si l'attaque est licite ou non + présent état présence d'un composant dans + une pile absent état absence d'un composant dans une + pile authentique état état d'un composant non usurpé + usurpé état état d'un composant usurpé par un autre usurpateur composant composant qui en usurpe un autre
Tableau IV
Le langage de description des composants permet d'écrire des règles,
qui comportent chacune un nombre variable de prédicats (condition logique booléenne) et éventuellement d'actions. Pour chaque composant, il existe huit types de règles. Les règles ont deux caractéristiques indépendantes: - elles peuvent être binaires (condition logique booléenne, donnant une valeur oui / non) ou fonctionnelles (condition logique impliquant une action de routage ou de contagion); et, - elles peuvent être "de propagation" (dans les composants vecteurs
des attaques) ou "d'absorption" (dans les composants cibles des attaques).
Dans un exemple, cinq règles de propagation et trois règles d'absorption sont données respectivement par le tableau V et par le tableau VI cidessous. règle type rôle exemple possibilité binaire définit quelles attaques un logiciel ne peut pas peuvent passer transporter un colis postal identification binaire assure l'identification et une attaque sera acceptée amont l'authentification des si le mot de passe a été composants amonts préalablement divulgué identification binaire assure l'identification et aval l'authentification des composants avals autorisation binaire définit quelles attaques un dispositif pare-feu sont autorisées à ("firewall") peut interdire passer les attaques de découverte par paquets "Ping" routage fonctionnelle définit vers quel un routeur envoie les composant diriger les messages mail vers le attaques serveur mail
Tableau V
règle type rôle exemple possibilité binaire définit quelles attaques un bureau peut absorber peuvent passer une bombe physique, mais pas une bombe logique identification binaire assure l'identification et une attaque sera acceptée amont l'authentification si le mot de passe a été éventuelle des préalablement divulgué composants amont contagion fonctionnelle définit quels états l'explosion d'un bureau doivent être propagés entraîne la destruction des vers quels composants équipements hébergés
Tableau VI
Les règles sont appliquées de la façon suivante. Chaque fois qu'une attaque se présente devant un composant (en cours), le moteur attaques / parades déroule le mécanisme illustré par le diagramme de la figure 13. Pour qu'une attaque soit propagée par un composant vecteur ou soit absorbée par un composant cible, chaque catégorie de règle binaire doit, soit
être vide, soit comporter une règle avec résultat positif.
Si l'attaque est acceptée par un composant vecteur, celui ci applique les règles de routage fonctionnel selon le mécanisme illustré par le diagramme de la figure 14a. De même, si l'attaque est acceptée par le composant cible, celui ci applique les règles de contagion selon le mécanisme illustré par le
diagramme de la figure 14b.
On va maintenant décrire les mécanismes de routage local et fonctionnel. Le routage a pour fonction de diriger les attaques d'un composant à l'autre, dans le but d'atteindre le point d'arrivée ou les points intermédiaires. Il
existe deux sortes de routages.
Premièrement, le routage fonctionnel, défini par l'utilisateur via les règles de routage, et qui permet de définir un nouveau composant intermédiaire avant d'atteindre le point d'arrivée. Ce composant est inséré dans la pile aval. Par exemple, un routeur décide de router un courrier électronique
venant de l'extérieur vers le serveur de messagerie.
Deuxièmement, le routage local, invisible de l'utilisateur, qui a pour effet de diriger l'attaque vers le prochain composant de la pile aval, selon le chemin le plus court. La table de routage local est utilisée à cet effet. On rappelle que cette table est construite automatiquement en fin de modélisation, selon le principe de recherche du plus court chemin. Dans un exemple, elle est
structurée sous forme de matrice (composant de) départ / arrivée.
Le routage fonctionnel permet d'assurer à la fois le fonctionnement nominal du système, et certaines fonctions de sécurité. Par exemple, un routeur qui envoi les paquets IP vers un dispositif pare-feu ("firewall") assure une fonction de sécurité. Cette fonction de sécurité peut être dégradée dans le
cas du détournement, ainsi qu'il va maintenant être décrit.
La technique de détournement, fondamentale dans les scénarios d'attaque, peut être prise en compte par le dispositif. Cette technique consiste à modifier la façon dont est fait le routage fonctionnel. Il existe trois sortes de
détournements, illustrées par le diagramme de la figure 15.
A la figure 15 on a représenté un exemple de chemin de propagation allant d'un client 151 à un serveur 155 à travers (dans cet ordre) un premier
routeur 152, un filtre 153 et un second routeur 154.
Un premier détournement est un détournement par contournement, symbolisé par la flèche 156. Dans l'exemple représenté, le routeur 152 est
altéré en sorte que son composant aval, le filtre 153, est supprimé.
Un deuxième détournement est un détournement par interception, symbolisé par les flèche 158a et 158b. Dans l'exemple représenté, le routeur 152 est altéré en sorte qu'un composant aval 157 est ajouté sur le chemin de propagation. Ce composant aval est un pirate (usurpant). Dans ce cas, le
serveur 155 est dit usurpé.
Un troisième détournement est un détournement par usurpation, symbolisé par la flèche 150. Dans l'exemple représenté, le routeur 154 est altéré en sorte que son composant aval, le serveur 155, est remplacé par un autre composant aval 159. Cet autre composant aval est un pirate (usurpant),
le serveur 155 est dit usurpé.
Un détournement peut être réalisé par tout composant ayant une fonction de routage, situé dans le chemin de l'attaque. Il est déclenché par la réunion de trois conditions: - le composant de routage a un état "altéré" (indiquant que ses tables de routage sont altérées); - le composant d'arrivée est "usurpé" (du moins pour l'usurpation et l'interception); et, - le composant de routage a une (ou plusieurs) règle particulière qui
prévoit le détournement.
On va maintenant présenter un premier mécanisme supplémentaire de
l'invention, constitué par les métriques de faisabilité et de non détection.
Les métriques ont pour but de compléter le langage de règles, qui est principalement axé sur la protection par prévention. Elles permettent de relativiser le succès ou l'échec des attaques, en calculant un coefficient de
faisabilité et de non détection, apportant ainsi la protection par détection.
Dans un exemple, il existe cinq métriques dont trois métriques de base, qui sont paramétrées lors de la modélisation, et deux métriques de probabilité
de sinistre, qui sont calculées lors de la simulation.
Pour éviter de tomber dans le travers de la complexité, les métriques de base sont évaluées sur un nombre restreint de niveaux, par exemple quatre niveaux. Cette échelle de niveaux doit être comprise comme une échelle logarithmique, c'est à dire que chaque niveau implique un coefficient multiplicateur par rapport au niveau inférieur. Les quatre niveaux
correspondent par exemple aux valeurs 0.1%, 1%, 10%, 100%.
Deux métriques de base relèvent du point de vue du défenseur. Il s'agit d'une métrique d'efficacité des parades (résistance), et d'une métrique d'efficacité de détection des attaques. Ces 2 métriques sont paramétrées par l'utilisateur pendant la phase de modélisation, indépendamment pour chaque règle de protection dans chaque composant, selon une échelle de valeurs telle
que faible, moyen, fort, absolu.
En outre, une métrique de base relève du point de vue de l'attaquant. Il s'agit d'une métrique de moyens de l'attaquant. Cette métrique comprend par exemple les aspects suivants: compétence, outils, argent, temps. Elle est paramétrée par l'utilisateur pendant la phase de simulation, de façon globale
pour l'attaquant, tous moyens, toutes attaques et toutes cibles confondus.
L'échelle de valeurs est par exemple: public, initié, spécialiste, expert.
Les métriques de probabilité de sinistre sont calculées par le moteur attaques / parades lors du passage dans chaque composant, puis consolidées par le moteur sur tout le chemin, puis sur tout le scénario. Il s'agit d'une métrique de probabilité de passage d'une attaque sur un composant, d'une part, et d'une métrique de probabilité de non détection d'une attaque sur un composant, d'autre part. De préférence, elles sont exprimées sur l'échelle à quatre niveaux des métriques de base, à laquelle on ajoute le niveau 0%, et elles sont calculées selon les formule suivantes: - probabilité de passage = (moyens de l'attaquant) / (efficacité de la protection); - probabilité de non détection = (moyens de l'attaquant) / (efficacité de
la détection).
Le tableau VII ci-dessous donne le calcul des métriques calculées.
efficacité 0.1% faible 0. 1% 1.0% 10.0% 100.0% du 1.0% moyen 0.0% 0.1% 1. 0% 10.0% défenseur 10.0% fort 0.0% 0.0% 0. 1% 1.0% 100.0% absolu 0.0% 0. 0% 0.0% 0. 1% moyens de l'attaquant 4 public initié spécialiste expert l___________________ _ 0.1% 1.0% 10.0% 100.0%
Tableau VII
On va maintenant décrire un autre mécanisme supplémentaire de
l'invention, qui fait partie de l'interface Homme / machine.
Avantageusement, l'interface Homme / machine présente une fonctionnalité dite "multi vues". Ceci n'est pas en soi une originalité, car la plupart des logiciels utilisent ce genre de fonctionnalité. Ce qui est original, par contre, c'est l'utilisation des vues pour aider l'utilisateur à maîtriser des systèmes complexes, grâce à une association entre les vues (logicielles) et les
*sous-systèmes (conceptuels).
Le système des "vues" est un élément important de l'interface Homme / machine, qui permet la modélisation de systèmes complexes. Son principe est de décomposer le système en plusieurs vues, dont une seule est affichée à l'écran dans la fenêtre principale, l'utilisateur pouvant passer alternativement d'une vue à l'autre. Tout composant peut être placé dans une
vue, dans une autre, ou dans plusieurs vues, au choix de l'utilisateur.
Le schéma de la figure 16 montre un exemple de représentation graphique d'un système (modélisé) selon trois vues superposées. Le serpentin
symbolise un chemin d'attaque passant par les trois vues.
Il n'y a pas de contraintes pour la définition des vues, et pour la répartition des composants dans les différentes vues d'un système. On peut par exemple mettre en place des vues associées aux différents métiers du
système (géographique, informatique, organisationnel).
Avantageusement, moyennant certains principes simples, pris isolément ou en combinaison, les vues deviennent cependant un élément de
structuration fonctionnelle des systèmes.
Selon un premier tel principe, chaque vue représente de préférence un
sous-système relativement autonome et indépendant du reste du système.
Selon un deuxième tel principe, on fait en sorte, de préférence, qu'il n'existe pas de relations de propagation ni de services entre deux vues. Seuls les composants communs à deux vues assurent la fonction d'interconnexion
entre les vues.
Selon un troisième tel principe, enfin, les règles des composants situés dans une vue ne doivent pas faire appel nommément à des composants situés
dans une autre vue.
Plus généralement, il y a deux façons de concevoir les vues. Soit les vues sont considérées comme des sous-systèmes de même niveau interconnectés entre eux (par exemple, des sites interconnectés via Internet, le composant commun étant Internet). Ou bien l'une des vues est considérée
comme une description globale du système, tandis que les autres représentent
des détails de tel ou tel composant complexe. Cette approche est appelée
approche hiérarchique et va être détaillée maintenant.
L'approche hiérarchique est très puissante, car elle permet d'assembler des composants détaillés et mis au point préalablement pour former par assemblage des systèmes très complexes et réalistes, tout en restant simple à
visualiser.
Dans cette approche, illustrée sous la forme d'un exemple donné à la figure 17, une vue supérieure présente le système global, qui contient un ou plusieurs composants représentant chacun un sous-système. Chaque vue inférieure donne le détail d'un sous système. A la figure, le serpentin symbolise
un chemin d'attaque passant par les deux vues.
Un composant A commun à la vue supérieure et à une vue inférieure, appelé "composant relais", représente le sous système vu du système global, et réciproquement. Le composant relais est l'unique interface entre les deux vues. Le composant relais assure l'étanchéité entre les vues, tout en
assurant la communication entre elles, selon un triple rôle.
Le composant relais assure tout d'abord un rôle de relais de routage.
En effet, il assure le routage des attaques dans les deux sens entre les deux vues. Il utilise pour cela tous les critères de routage disponibles dans le
langage de règles.
Le composant relais assure ensuite un rôle de relais de service. En effet, il peut avoir des relations de service, partant ou aboutissant, dans les deux vues. Ceci permet de désigner un composant d'une vue à l'autre via l'indexation.
Le composant relais assure enfin un rôle de relais de contagion d'état.
A cet effet, il assure pour la vue supérieure une vision synthétique de la vue
inférieure, via une contagion des principaux états représentatifs de cette vue.
A la figure 18, sur laquelle les mêmes éléments qu'aux figures 1 et 2 portent les mêmes références, on a représenté le schéma synoptique d'un exemple de réalisation d'un dispositif selon l'invention. Ce dispositif convient
pour la mise en òuvre du procédé selon l'invention.
Dans cet exemple, le dispositif est implémenté dans un ordinateur à usage général comprenant un microprocesseur 10. L'interface Homme / machine 15 et le moteur attaques / parades 16 sont mis en oeuvre sous la forme de modules logiciels, sauvegardés dans une mémoire 17 et plus particulièrement dans une mémoire à lecture seule (ROM). Ils sont exécutés par le microprocesseur 10 lorsqu'ils sont chargés dans la mémoire vive de
l'ordinateur.
Pour assurer l'entrée de données par l'utilisateur, le dispositif comprend un clavier 19b, et en général également une souris (non représentée) ou similaire. Pour l'affichage des données, notamment pour l'affichage de la représentation graphique du système modélisés sous la forme d'une on plusieurs vues, le dispositif comprend aussi un écran. Ces éléments
sont ceux qui équipent l'ordinateur.
Enfin, le dispositif comprend une mémoire vive 18, en particulier une mémoire à accès aléatoire (RAM), dans laquelle les fichiers 11, 12, 13 et 14
peuvent être sauvegardés.
Claims (44)
1. Procédé d'analyse de la sécurité d'un système d'information comprenant: - une phase de modélisation (1,2), comprenant la modélisation du système d'information, - une phase de simulation, comprenant la spécification (3) et la
simulation (4) d'attaques potentielles contre le système d'information.
2. Procédé selon la revendication 1, suivant lequel la phase de modélisation comprend la spécification (1) de l'architecture du système avec un ensemble de composants du système et des relations entre lesdits
composants.
3. Procédé selon la revendication 2, suivant lequel, un nom étant associé à chaque composant, un ou plusieurs adjectifs peuvent aussi être associés audit composant, lesquels adjectifs permettent de désigner ledit
composant sans le nommer.
4. Procédé selon la revendication 2 ou la revendication 3, suivant lequel des états déterminés sont associés à chaque composant du système d'information, chaque état pouvant prendre une valeur saine et une ou
plusieurs valeurs non saines.
5. Procédé selon la revendication 4, suivant lequel certains au moins desdits états se rapportent respectivement à l'activité, à la confidentialité, à
l'intégrité et/ou à la disponibilité du composant auquel ils sont associés.
6. Procédé selon l'une quelconque des revendications 2 à 5, suivant
lequel un nom prétendu peut être associé à un composant déterminé quelconque, notamment dans le cas o ledit composant déterminé est
usurpateur.
7. Procédé selon l'une quelconque des revendications 2 à 6, suivant
lequel un lien vers un autre composant peut être associé à un composant déterminé quelconque, notamment dans le cas o ledit composant déterminé
est usurpé et o ledit autre composant est usurpateur.
8. Procédé selon l'une quelconque des revendications 2 à 7, suivant
lequel les relations entre deux composants déterminés quelconques, comprennent des relations de propagation bidirectionnelles susceptibles de
véhiculer des attaques dans les deux sens.
9. Procédé selon l'une quelconque des revendications 2 à 8, suivant
lequel les relations entre deux composants déterminés quelconques, comprennent des relations de service permettant de désigner un composant à
partir d'un autre composant.
10. Procédé selon la revendication 2, suivant lequel la phase de modélisation comprend en outre la spécification (2) d'un ensemble de règles de
comportement associées aux composants du système.
11. Procédé selon la revendication 10, suivant lequel chaque règle de comportement comprend un ou plusieurs prédicats, et/ou une ou plusieurs actions.
12. Procédé selon la revendication 10 ou la revendication 11, suivant lequel les règles de comportement comprennent des règles de propagation d'attaques, ces règles étant par exemple mises en oeuvre dans des composants qui sont des vecteurs d'attaques, et des règles d'absorption d'attaques, ces règles étant par exemple mise en oeuvre dans des composants
qui sont la cible d'attaques.
13. Procédé selon l'une quelconque des revendications 10 à 12,
suivant lequel les règles de comportement comprennent des règles binaires, par exemple des conditions logiques booléennes donnant une valeur de type oui / non, et/ou des règles fonctionnelles, par exemple des conditions logiques impliquant une action de routage (pour une règle de propagation) ou de
contagion (pour une règle d'absorption).
14. Procédé selon l'une quelconque des revendications 2 à 13
comprenant, à la fin de la phase de modélisation (figure 3), la construction (35) d'une table de routage local, permettant de diriger une attaque d'un composant
de départ vers un composant d'arrivée.
15. Procédé selon la revendication 14, suivant lequel la table de routage local est générée de façon automatique suivant le principe du plus
court chemin entre le composant de départ et le composant d'arrivée.
16. Procédé selon l'une quelconque des revendications 3 à 15, suivant
lequel l'étape de simulation des attaques comprend la mise à jour de l'état d'un
composant du système altéré par une attaque réussie.
17. Procédé selon la revendication 16, suivant lequel la phase de simulation comprend en outre la constitution d'un fichier ou journal des attaques, contenant l'historique des changements de l'état des composants consécutifs à des attaques réussies, notamment pour permettre un traitement
ultérieur par un utilisateur.
18. Procédé selon l'une quelconque des revendications précédentes,
suivant lequel les attaques comprennent des attaques élémentaires
correspondant à des valeurs d'états non saines.
19. Procédé selon l'une quelconque des revendications précédentes,
suivant lequel les attaques comprennent en outre une attaque spéciale d'usurpation.
20. Procédé selon l'une quelconque des revendications précédentes,
suivant lequel une attaque est définie, notamment, par un type d'attaque, un
type de protocole, et des éléments de chemin d'attaque.
21. Procédé selon la revendication 20, suivant lequel les éléments de chemin d'attaque comprennent un composant de départ, un composant d'arrivée, un composant cible, et le cas échéant un ou plusieurs composants intermédiaires.
22. Procédé selon la revendication 20 ou la revendication 21, suivant lequel la liste des composants déjà traversés par une attaque est sauvegardée
dans au moins une ou plusieurs piles amont.
23. Procédé selon la revendication 22, suivant lequel les piles amont comprennent une pile (110) contenant la liste exhaustive de tous les
composants traversés, désignés par leur nom réel.
24. Procédé selon la revendication 22 ou la revendication 23, suivant lequel les piles amont comprennent une pile (120) contenant la liste des seuls composants traversés qui sont opaques, désignés par leur nom réel ou, le cas
échéant, par leur nom prétendu.
25. Procédé selon l'une quelconque des revendications 20 à 24,
suivant lequel la liste des composants destinataires d'une attaque est
sauvegardée dans au moins une pile aval (130).
26. Procédé selon l'une quelconque des revendications 10 à 25,
suivant lequel les attaques sont définies dans un langage utilisant les mêmes
mots qu'un langage dans lequel les règles de comportement sont définies.
27. Procédé selon l'une quelconque des revendications précédentes,
suivant lequel la phase de modélisation et/ou la phase de simulation sont mises en oeuvre par un utilisateur au moyen d'une interface Homme/machine comportant une fonctionnalité multi vues, suivant laquelle une représentation
graphique du système est présentée à l'utilisateur en plusieurs vues.
28. Procédé selon la revendication 27, suivant lequel chaque vue représente un sous-système du système, qui est relativement autonome et
indépendant du reste du système.
29. Procédé selon la revendication 27 ou la revendication 28, suivant lequel la fonction d'interconnexion entre les composants compris dans deux vues distinctes est assurée seulement via le composant commun ou les
composants communs aux deux vues.
30. Procédé selon l'une quelconque des revendications 27 à 29,
suivant lequel les règles de comportement des composants appartenant à une vue ne font pas appel nommément à des composants appartenant à une autre vue.
31 Procédé selon l'une quelconque des revendications 27 à 30, suivant
lequel les vues sont associées à des sous-systèmes respectifs, par exemple de même niveau, qui sont interconnectés entre eux via au moins un composant
commun.
32. Procédé selon l'une quelconque des revendications 27 à 30,
suivant lequel une vue supérieure est associée au système dans son ensemble, tandis qu'une ou plusieurs vues inférieures sont respectivement
associées à un sous-système déterminé du système.
33. Procédé selon la revendication 32, suivant lequel un composant déterminé, commun à la vue supérieure et à une vue inférieure déterminée, représente le sous système correspondant vu du système dans son ensemble,
et réciproquement.
34. Procédé selon la revendication 33, suivant lequel ledit composant commun est l'unique interface entre les la vue supérieure et ladite vue
inférieure déterminée.
35. Procédé selon l'une quelconque des revendications précédentes,
suivant lequel la phase de modélisation comprend en outre la spécification d'une ou plusieurs métriques de base respectivement associées aux
composants.
36. Procédé selon la revendication 35, suivant lequel les métriques de base comprennent, une métrique d'efficacité des parades, une métrique d'efficacité de détection des attaques, et/ou une métrique des moyens d'un attaquant.
37. Procédé selon l'une quelconque des revendications précédentes,
suivant lequel la phase de simulation comprend en le calcul d'une ou plusieurs
métriques de probabilité de sinistre.
38. Procédé selon la revendication 37, suivant lequel les métriques de probabilité de sinistre comprennent une métrique de probabilité de passage
d'une attaque sur un composant.
39. Procédé selon les revendications 36 et 38, suivant lequel la
métrique de probabilité de passage d'une attaque sur un composant est calculée suivant la formule " probabilité de passage = (moyens de
l'attaquant) / (efficacité de la protection)".
40. Procédé selon la revendication 37, suivant lequel les métriques de probabilité de sinistre comprennent une métrique de probabilité de non
détection d'une attaque sur un composant.
41. Procédé selon les revendications 36 et 40, suivant lequel la
métrique de probabilité de non détection d'une attaque sur un composant est calculée suivant la formule "probabilité de non détection = (moyens de
l'attaquant) / (efficacité de la détection)".
42. Dispositif pour la mise en oeuvre d'un procédé selon l'une
quelconque des revendications précédentes, comprenant une interface
Homme/ machine (15) pour la mise en oeuvre de la phase de modélisation et/ou un moteur attaques / parades (16) pour la mise en oeuvre de la phase de simulation
43. Dispositif selon la revendication 42, dans lequel l'interface Homme/ machine présente une fonctionnalité d'affichage en multi vues du
système modélisé.
44. Dispositif selon la revendication 42 ou la revendication 43, dans lequel l'interface Homme / machine permet d'afficher le système modélisé
selon un modèle composants / relations.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0214279A FR2847360B1 (fr) | 2002-11-14 | 2002-11-14 | Procede et dispositif d'analyse de la securite d'un systeme d'information |
| US10/534,855 US20060015943A1 (en) | 2002-11-14 | 2003-11-05 | Method and device for analyzing an information sytem security |
| PCT/FR2003/003309 WO2004046974A1 (fr) | 2002-11-14 | 2003-11-05 | Procede et dispositif d'analyse de la securite d'un systeme d'information |
| AU2003295010A AU2003295010A1 (en) | 2002-11-14 | 2003-11-05 | Method and device for analyzing an information system security |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0214279A FR2847360B1 (fr) | 2002-11-14 | 2002-11-14 | Procede et dispositif d'analyse de la securite d'un systeme d'information |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2847360A1 true FR2847360A1 (fr) | 2004-05-21 |
| FR2847360B1 FR2847360B1 (fr) | 2005-02-04 |
Family
ID=32187619
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0214279A Expired - Lifetime FR2847360B1 (fr) | 2002-11-14 | 2002-11-14 | Procede et dispositif d'analyse de la securite d'un systeme d'information |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US20060015943A1 (fr) |
| AU (1) | AU2003295010A1 (fr) |
| FR (1) | FR2847360B1 (fr) |
| WO (1) | WO2004046974A1 (fr) |
Families Citing this family (97)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7194769B2 (en) * | 2003-12-11 | 2007-03-20 | Massachusetts Institute Of Technology | Network security planning architecture |
| US7711796B2 (en) | 2006-06-12 | 2010-05-04 | Icontrol Networks, Inc. | Gateway registry methods and systems |
| US8635350B2 (en) | 2006-06-12 | 2014-01-21 | Icontrol Networks, Inc. | IP device discovery systems and methods |
| US20160065414A1 (en) | 2013-06-27 | 2016-03-03 | Ken Sundermeyer | Control system user interface |
| US20090077623A1 (en) | 2005-03-16 | 2009-03-19 | Marc Baum | Security Network Integrating Security System and Network Devices |
| US11316958B2 (en) | 2008-08-11 | 2022-04-26 | Icontrol Networks, Inc. | Virtual device systems and methods |
| US9531593B2 (en) | 2007-06-12 | 2016-12-27 | Icontrol Networks, Inc. | Takeover processes in security network integrated with premise security system |
| US20170118037A1 (en) | 2008-08-11 | 2017-04-27 | Icontrol Networks, Inc. | Integrated cloud system for premises automation |
| EP1738540B1 (fr) | 2004-03-16 | 2017-10-04 | Icontrol Networks, Inc. | Systeme de gestion d'antecedents |
| US11677577B2 (en) | 2004-03-16 | 2023-06-13 | Icontrol Networks, Inc. | Premises system management using status signal |
| US11277465B2 (en) | 2004-03-16 | 2022-03-15 | Icontrol Networks, Inc. | Generating risk profile using data of home monitoring and security system |
| US9729342B2 (en) | 2010-12-20 | 2017-08-08 | Icontrol Networks, Inc. | Defining and implementing sensor triggered response rules |
| US11343380B2 (en) | 2004-03-16 | 2022-05-24 | Icontrol Networks, Inc. | Premises system automation |
| US10142392B2 (en) | 2007-01-24 | 2018-11-27 | Icontrol Networks, Inc. | Methods and systems for improved system performance |
| US10721087B2 (en) | 2005-03-16 | 2020-07-21 | Icontrol Networks, Inc. | Method for networked touchscreen with integrated interfaces |
| US10339791B2 (en) | 2007-06-12 | 2019-07-02 | Icontrol Networks, Inc. | Security network integrated with premise security system |
| US9141276B2 (en) | 2005-03-16 | 2015-09-22 | Icontrol Networks, Inc. | Integrated interface for mobile device |
| US10156959B2 (en) | 2005-03-16 | 2018-12-18 | Icontrol Networks, Inc. | Cross-client sensor user interface in an integrated security network |
| US11244545B2 (en) | 2004-03-16 | 2022-02-08 | Icontrol Networks, Inc. | Cross-client sensor user interface in an integrated security network |
| US11811845B2 (en) | 2004-03-16 | 2023-11-07 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
| US11916870B2 (en) | 2004-03-16 | 2024-02-27 | Icontrol Networks, Inc. | Gateway registry methods and systems |
| US11113950B2 (en) | 2005-03-16 | 2021-09-07 | Icontrol Networks, Inc. | Gateway integrated with premises security system |
| US11159484B2 (en) | 2004-03-16 | 2021-10-26 | Icontrol Networks, Inc. | Forming a security network including integrated security system components and network devices |
| US10522026B2 (en) | 2008-08-11 | 2019-12-31 | Icontrol Networks, Inc. | Automation system user interface with three-dimensional display |
| US10200504B2 (en) | 2007-06-12 | 2019-02-05 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
| US10127802B2 (en) | 2010-09-28 | 2018-11-13 | Icontrol Networks, Inc. | Integrated security system with parallel processing architecture |
| US11368429B2 (en) | 2004-03-16 | 2022-06-21 | Icontrol Networks, Inc. | Premises management configuration and control |
| US11201755B2 (en) | 2004-03-16 | 2021-12-14 | Icontrol Networks, Inc. | Premises system management using status signal |
| US10237237B2 (en) | 2007-06-12 | 2019-03-19 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US11489812B2 (en) | 2004-03-16 | 2022-11-01 | Icontrol Networks, Inc. | Forming a security network including integrated security system components and network devices |
| US11582065B2 (en) | 2007-06-12 | 2023-02-14 | Icontrol Networks, Inc. | Systems and methods for device communication |
| US8095982B1 (en) | 2005-03-15 | 2012-01-10 | Mu Dynamics, Inc. | Analyzing the security of communication protocols and channels for a pass-through device |
| US8095983B2 (en) | 2005-03-15 | 2012-01-10 | Mu Dynamics, Inc. | Platform for analyzing the security of communication protocols and channels |
| US9306809B2 (en) | 2007-06-12 | 2016-04-05 | Icontrol Networks, Inc. | Security system with networked touchscreen |
| US10999254B2 (en) | 2005-03-16 | 2021-05-04 | Icontrol Networks, Inc. | System for data routing in networks |
| US11700142B2 (en) | 2005-03-16 | 2023-07-11 | Icontrol Networks, Inc. | Security network integrating security system and network devices |
| US20110128378A1 (en) | 2005-03-16 | 2011-06-02 | Reza Raji | Modular Electronic Display Platform |
| US11615697B2 (en) | 2005-03-16 | 2023-03-28 | Icontrol Networks, Inc. | Premise management systems and methods |
| US11496568B2 (en) | 2005-03-16 | 2022-11-08 | Icontrol Networks, Inc. | Security system with networked touchscreen |
| US20170180198A1 (en) | 2008-08-11 | 2017-06-22 | Marc Baum | Forming a security network including integrated security system components |
| US20120324566A1 (en) | 2005-03-16 | 2012-12-20 | Marc Baum | Takeover Processes In Security Network Integrated With Premise Security System |
| WO2007143226A2 (fr) | 2006-06-09 | 2007-12-13 | Massachusetts Institute Of Technology | Génération d'un graphe d'attaque à pré-requis multiples |
| US10079839B1 (en) | 2007-06-12 | 2018-09-18 | Icontrol Networks, Inc. | Activation of gateway device |
| US7891003B2 (en) * | 2006-06-14 | 2011-02-15 | Microsoft Corporation | Enterprise threat modeling |
| US8316447B2 (en) | 2006-09-01 | 2012-11-20 | Mu Dynamics, Inc. | Reconfigurable message-delivery preconditions for delivering attacks to analyze the security of networked systems |
| US9172611B2 (en) * | 2006-09-01 | 2015-10-27 | Spirent Communications, Inc. | System and method for discovering assets and functional relationships in a network |
| US7958230B2 (en) | 2008-09-19 | 2011-06-07 | Mu Dynamics, Inc. | Test driven deployment and monitoring of heterogeneous network systems |
| US11706279B2 (en) | 2007-01-24 | 2023-07-18 | Icontrol Networks, Inc. | Methods and systems for data communication |
| US7633385B2 (en) | 2007-02-28 | 2009-12-15 | Ucontrol, Inc. | Method and system for communicating with and controlling an alarm system from a remote server |
| US8451986B2 (en) | 2007-04-23 | 2013-05-28 | Icontrol Networks, Inc. | Method and system for automatically providing alternate network access for telecommunications |
| US11237714B2 (en) | 2007-06-12 | 2022-02-01 | Control Networks, Inc. | Control system user interface |
| US11316753B2 (en) | 2007-06-12 | 2022-04-26 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US10523689B2 (en) | 2007-06-12 | 2019-12-31 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
| US11601810B2 (en) | 2007-06-12 | 2023-03-07 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US11423756B2 (en) | 2007-06-12 | 2022-08-23 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US11212192B2 (en) | 2007-06-12 | 2021-12-28 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US11089122B2 (en) | 2007-06-12 | 2021-08-10 | Icontrol Networks, Inc. | Controlling data routing among networks |
| US11646907B2 (en) | 2007-06-12 | 2023-05-09 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US11218878B2 (en) | 2007-06-12 | 2022-01-04 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
| US8356353B2 (en) | 2007-06-26 | 2013-01-15 | Core Sdi, Incorporated | System and method for simulating computer network attacks |
| US11831462B2 (en) | 2007-08-24 | 2023-11-28 | Icontrol Networks, Inc. | Controlling data routing in premises management systems |
| US7774637B1 (en) | 2007-09-05 | 2010-08-10 | Mu Dynamics, Inc. | Meta-instrumentation for security analysis |
| US11916928B2 (en) | 2008-01-24 | 2024-02-27 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
| US20170185278A1 (en) | 2008-08-11 | 2017-06-29 | Icontrol Networks, Inc. | Automation system user interface |
| US8352729B2 (en) * | 2008-07-29 | 2013-01-08 | International Business Machines Corporation | Secure application routing |
| US11758026B2 (en) | 2008-08-11 | 2023-09-12 | Icontrol Networks, Inc. | Virtual device systems and methods |
| US11792036B2 (en) | 2008-08-11 | 2023-10-17 | Icontrol Networks, Inc. | Mobile premises automation platform |
| US10530839B2 (en) | 2008-08-11 | 2020-01-07 | Icontrol Networks, Inc. | Integrated cloud system with lightweight gateway for premises automation |
| US11258625B2 (en) | 2008-08-11 | 2022-02-22 | Icontrol Networks, Inc. | Mobile premises automation platform |
| US11729255B2 (en) | 2008-08-11 | 2023-08-15 | Icontrol Networks, Inc. | Integrated cloud system with lightweight gateway for premises automation |
| US8638211B2 (en) | 2009-04-30 | 2014-01-28 | Icontrol Networks, Inc. | Configurable controller and interface for home SMA, phone and multimedia |
| US20110066851A1 (en) | 2009-09-14 | 2011-03-17 | International Business Machines Corporation | Secure Route Discovery Node and Policing Mechanism |
| US8463860B1 (en) | 2010-05-05 | 2013-06-11 | Spirent Communications, Inc. | Scenario based scale testing |
| US8547974B1 (en) | 2010-05-05 | 2013-10-01 | Mu Dynamics | Generating communication protocol test cases based on network traffic |
| US8836467B1 (en) | 2010-09-28 | 2014-09-16 | Icontrol Networks, Inc. | Method, system and apparatus for automated reporting of account and sensor zone information to a central station |
| US11750414B2 (en) | 2010-12-16 | 2023-09-05 | Icontrol Networks, Inc. | Bidirectional security sensor communication for a premises security system |
| US9147337B2 (en) | 2010-12-17 | 2015-09-29 | Icontrol Networks, Inc. | Method and system for logging security event data |
| US9106514B1 (en) | 2010-12-30 | 2015-08-11 | Spirent Communications, Inc. | Hybrid network software provision |
| US8726376B2 (en) * | 2011-03-11 | 2014-05-13 | Openet Telecom Ltd. | Methods, systems and devices for the detection and prevention of malware within a network |
| EP2506519A1 (fr) * | 2011-03-25 | 2012-10-03 | EADS Deutschland GmbH | Procédé permettant de déterminer l'intégrité dans un système d'informations collaboratrices évolutif |
| US8464219B1 (en) | 2011-04-27 | 2013-06-11 | Spirent Communications, Inc. | Scalable control system for test execution and monitoring utilizing multiple processors |
| US8972543B1 (en) | 2012-04-11 | 2015-03-03 | Spirent Communications, Inc. | Managing clients utilizing reverse transactions |
| US9521138B2 (en) | 2013-06-14 | 2016-12-13 | Go Daddy Operating Company, LLC | System for domain control validation |
| US9178888B2 (en) | 2013-06-14 | 2015-11-03 | Go Daddy Operating Company, LLC | Method for domain control validation |
| US9141789B1 (en) | 2013-07-16 | 2015-09-22 | Go Daddy Operating Company, LLC | Mitigating denial of service attacks |
| US11146637B2 (en) | 2014-03-03 | 2021-10-12 | Icontrol Networks, Inc. | Media content management |
| US11405463B2 (en) | 2014-03-03 | 2022-08-02 | Icontrol Networks, Inc. | Media content management |
| US11184401B2 (en) * | 2015-10-28 | 2021-11-23 | Qomplx, Inc. | AI-driven defensive cybersecurity strategy analysis and recommendation system |
| US10397258B2 (en) | 2017-01-30 | 2019-08-27 | Microsoft Technology Licensing, Llc | Continuous learning for intrusion detection |
| EP3711279A1 (fr) | 2017-11-15 | 2020-09-23 | XM Cyber Ltd. | Choix sélectif entre une attaque réelle et une simulation/évaluation pour valider une vulnérabilité d'un noeud de réseau pendant l'exécution d'une campagne d'essais de pénétration |
| US11283827B2 (en) | 2019-02-28 | 2022-03-22 | Xm Cyber Ltd. | Lateral movement strategy during penetration testing of a networked system |
| US11206281B2 (en) | 2019-05-08 | 2021-12-21 | Xm Cyber Ltd. | Validating the use of user credentials in a penetration testing campaign |
| US10880326B1 (en) | 2019-08-01 | 2020-12-29 | Xm Cyber Ltd. | Systems and methods for determining an opportunity for node poisoning in a penetration testing campaign, based on actual network traffic |
| US11005878B1 (en) | 2019-11-07 | 2021-05-11 | Xm Cyber Ltd. | Cooperation between reconnaissance agents in penetration testing campaigns |
| US11575700B2 (en) | 2020-01-27 | 2023-02-07 | Xm Cyber Ltd. | Systems and methods for displaying an attack vector available to an attacker of a networked system |
| WO2021216163A2 (fr) * | 2020-02-17 | 2021-10-28 | Qomplx, Inc. | Système d'analyse et de recommandation de stratégie de cybersécurité défensive piloté par intelligence artificielle |
| US11582256B2 (en) | 2020-04-06 | 2023-02-14 | Xm Cyber Ltd. | Determining multiple ways for compromising a network node in a penetration testing campaign |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6061505A (en) * | 1994-07-22 | 2000-05-09 | Nortel Networks Corporation | Apparatus and method for providing topology information about a network |
| US6088804A (en) * | 1998-01-12 | 2000-07-11 | Motorola, Inc. | Adaptive system and method for responding to computer network security attacks |
| US6343362B1 (en) * | 1998-09-01 | 2002-01-29 | Networks Associates, Inc. | System and method providing custom attack simulation language for testing networks |
| US6957348B1 (en) * | 2000-01-10 | 2005-10-18 | Ncircle Network Security, Inc. | Interoperability of vulnerability and intrusion detection systems |
| US7315801B1 (en) * | 2000-01-14 | 2008-01-01 | Secure Computing Corporation | Network security modeling system and method |
| US6535227B1 (en) * | 2000-02-08 | 2003-03-18 | Harris Corporation | System and method for assessing the security posture of a network and having a graphical user interface |
| US6944673B2 (en) * | 2000-09-08 | 2005-09-13 | The Regents Of The University Of Michigan | Method and system for profiling network flows at a measurement point within a computer network |
| US7013395B1 (en) * | 2001-03-13 | 2006-03-14 | Sandra Corporation | Method and tool for network vulnerability analysis |
| US20020199122A1 (en) * | 2001-06-22 | 2002-12-26 | Davis Lauren B. | Computer security vulnerability analysis methodology |
| US7289456B2 (en) * | 2002-04-08 | 2007-10-30 | Telcordia Technologies, Inc. | Determining and provisioning paths within a network of communication elements |
| US7379857B2 (en) * | 2002-05-10 | 2008-05-27 | Lockheed Martin Corporation | Method and system for simulating computer networks to facilitate testing of computer network security |
| US7472421B2 (en) * | 2002-09-30 | 2008-12-30 | Electronic Data Systems Corporation | Computer model of security risks |
| US6952779B1 (en) * | 2002-10-01 | 2005-10-04 | Gideon Cohen | System and method for risk detection and analysis in a computer network |
-
2002
- 2002-11-14 FR FR0214279A patent/FR2847360B1/fr not_active Expired - Lifetime
-
2003
- 2003-11-05 AU AU2003295010A patent/AU2003295010A1/en not_active Abandoned
- 2003-11-05 US US10/534,855 patent/US20060015943A1/en not_active Abandoned
- 2003-11-05 WO PCT/FR2003/003309 patent/WO2004046974A1/fr not_active Application Discontinuation
Non-Patent Citations (4)
| Title |
|---|
| APOSTAL D ET AL: "Checkmate network security modeling", PROCEEDINGS DARPA INFORMATION SURVIVABILITY CONFERENCE AND EXPOSITION II. DISCEX'01, PROCEEDINGS DARPA INFORMATION SURVIVABILITY CONFERENCE AND EXPOSITION II. DISCEX'01, ANAHEIM, CA, USA, 12-14 JUNE 2001, 2001, Los Alamitos, CA, USA, IEEE Comput. Soc, USA, pages 214 - 226 vol.1, XP002255222, ISBN: 0-7695-1212-7 * |
| HYUNG JONG KIM ET AL: "Vulnerability assessment simulation for information infrastructure protection", INFRASTRUCTURE SECURITY. INTERNATIONAL CONFERENCE, INFRASEC 2002. PROCEEDINGS (LECTURE NOTES IN COMPUTER SCIENCE VOL.2437), INFRASTRUCTURE SECURITY. INTERNATIONAL CONFERENCE, INFRASEC 2002. PROCEEDINGS, BRISTOL, UK, 1-3 OCT. 2002, 2002, Berlin, Germany, Springer-Verlag, Germany, pages 145 - 161, XP002255223, ISBN: 3-540-44309-6 * |
| SUNG-DO CHI ET AL: "Network security modeling and cyber attack simulation methodology", INFORMATION SECURITY AND PRIVACY. 6TH AUSTRALASIAN CONFERENCE, ACISP 2001. PROCEEDINGS (LECTURE NOTES IN COMPUTER SCIENCE VOL.2119), INFORMATION SECURITY AND PRIVACY. 6TH AUSTRALASIAN CONFERENCE, ACISP 2001. PROCEEDINGS, SYDNEY, NSW, AUSTRALIA, 11-13, 2001, Berlin, Germany, Springer-Verlag, Germany, pages 320 - 333, XP002255221, ISBN: 3-540-42300-1 * |
| ZHOU B: "Risk analysis and assessment using object-oriented techniques", PROCEEDINGS TECHNOLOGY OF OBJECT-ORIENTED LANGUAGES AND SYSTEMS (CAT. NO.PR00393), PROCEEDINGS TECHNOLOGY OF OBJECT-ORIENTED LANGUAGES AND SYSTEMS. TOOLS 31, NANJING, CHINA, 22-25 SEPT. 1999, 1999, Los Alamitos, CA, USA, IEEE Comput. Soc, USA, pages 142 - 145, XP002255224, ISBN: 0-7695-0393-4 * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20060015943A1 (en) | 2006-01-19 |
| WO2004046974A1 (fr) | 2004-06-03 |
| FR2847360B1 (fr) | 2005-02-04 |
| AU2003295010A1 (en) | 2004-06-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2847360A1 (fr) | Procede et dispositif d'analyse de la securite d'un systeme d'information | |
| Rader et al. | Identifying patterns in informal sources of security information | |
| Cole | Advanced persistent threat: understanding the danger and how to protect your organization | |
| Brody et al. | Flying under the radar: social engineering | |
| Shinder et al. | Scene of the Cybercrime | |
| Rawat et al. | Dark web—onion hidden service discovery and crawling for profiling morphing, unstructured crime and vulnerabilities prediction | |
| Indrajit | Social engineering framework: Understanding the deception approach to human element of security | |
| Hodson | Cyber risk management: Prioritize threats, identify vulnerabilities and apply controls | |
| Kroll et al. | Enhancing cybersecurity via artificial intelligence: Risks, rewards, and frameworks | |
| Vishwanath | The weakest link: How to diagnose, detect, and defend users from phishing | |
| Sachs et al. | Cyber adversary characterization: Auditing the hacker mind | |
| CN110611673B (zh) | Ip信用计算方法、装置、电子设备及介质 | |
| Onyebuchi | Signature based network intrusion detection system using feature selection on android | |
| Kassem | Intelligent system using machine learning techniques for security assessment and cyber intrusion detection | |
| Warren et al. | How might crime-scripts be used to support the understanding and policing of cloud crime? | |
| Bhusan et al. | Fundamental of Cyber Security: Principles, Theory and Practices | |
| St-Hilaire | Digital Risk Governance: Security Strategies for the Public and Private Sectors | |
| Donato | Computer criminal profiling applied to digital investigations | |
| Colorossi | Cyber security | |
| Kabanda | Anchoring AI/Machine Learning on the African Technological Innovation and Investment Table | |
| Pereira et al. | Governance of ICT Security: A Perspective from the JRC | |
| Sobesto | Empirical studies based on honeypots for characterizing attackers behavior | |
| Das | Ransomware: Penetration Testing and Contingency Planning | |
| Othman | Information Security Management for Cyber Security Challenges in Smart Cities Security and Privacy | |
| US20220255962A1 (en) | Systems and methods for creation, management, and storage of honeyrecords |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| CD | Change of name or company name | ||
| TP | Transmission of property | ||
| CD | Change of name or company name | ||
| PLFP | Fee payment |
Year of fee payment: 14 |
|
| PLFP | Fee payment |
Year of fee payment: 15 |
|
| PLFP | Fee payment |
Year of fee payment: 16 |
|
| PLFP | Fee payment |
Year of fee payment: 17 |
|
| PLFP | Fee payment |
Year of fee payment: 18 |
|
| PLFP | Fee payment |
Year of fee payment: 19 |
|
| PLFP | Fee payment |
Year of fee payment: 20 |