Concept: Patterns de sécurité
Relations
Description principale

Introduction

La "sécurité" est généralement perçue comme une discipline complexe et abrutissante. Un "pattern" (ou modèle) est un terme que la plupart des gens pensent comprendre intuitivement car la reconnaissance et la généralisation des modèles perçus font naturellement partie de l'éducation humaine. Pour cet exercice, les définitions suivantes sont utilisées en tant que définitions de travail :

La sécurité désigne "La condition d'un système résultant de l'établissement et du maintien de mesures pour protéger le système". [1]

"Un pattern est l'abstraction d'une forme concrète qui se répète dans des contextes non arbitraires spécifiques". [2]

La tentative d'associer ces deux termes, "sécurité" et "patterns", peut donc sembler paradoxale. La production de patterns de sécurité a été tentée à plusieurs reprises (voir l'annexe A). Dans le présent document, nous nous sommes efforcés de collecter et de codifier le matériel ayant été rassemblé pendant plusieurs années par divers spécialistes en sécurité, à partir de différents suivis client et de produire une ossature pour les patterns de sécurité IBM. La définition de travail des "patterns de sécurité" dans le contexte du présent document est la suivante :

Abstraction des conditions résultant de l'établissement et du maintien de mesures récurrentes, utilisées pour protéger le système.

La communauté de développement de logiciels déploie actuellement des efforts pour établir [3] une méthodologie pour le développement de patterns.

Toute discipline scientifique ou d'ingénierie est basée sur une terminologie commune permettant d'exprimer ses concepts et sur un langage permettant de relier ces derniers entre eux. L'objectif des patterns, au sein de la communauté de développement de logiciels, est de créer une base de documentation technique afin d'aider les développeurs à résoudre les incidents récurrents, rencontrés tout au long du processus de développement de logiciels. Les patterns aident à créer un langage partagé pour communiquer les connaissances et l'expérience sur ces incidents et leurs solutions. La codification formelle de ces solutions et de leurs relations permet de capturer la base de connaissances qui détermine la compréhension d'architectures de qualité répondant aux exigences de leurs utilisateurs. L'élaboration d'un langage de pattern commun pour acheminer les structures et les mécanismes des architectures permet de raisonner intelligiblement sur ces dernières. L'accent initial n'est pas tant mis sur la technologie que sur la création d'une culture susceptible de documenter et de prendre en charge une architecture et une conception d'ingénierie saines. [4]

Le point fondamental de confusion est que les patterns, comme la beauté, semblent résider dans le regard de l'observateur. Par conséquent, si vous réunissez cinq experts en sécurité, ils définiront des patterns spécifiques de leur domaine d'intérêt.

C'est la raison pour laquelle il est utile de faire ici une digression sur les "rôles" afin d'aider à grouper les patterns selon des intérêts communs. 

Qui est le premier ?

Dans le monde du développement de logiciels, certains conçoivent des objets, d'autres créent des images et rédigent des documents, d'autres écrivent du code et d'autres enfin rassemblent tous ces éléments et fournissent des systèmes informatiques.

Chaque organisation possède généralement une façon propre de définir les tâches, mais il existe des rôles archétypes.

Un archétype est le modèle idéalisé d'une personne, d'un objet ou d'un concept à partir duquel des instances similaires sont dérivées, copiées, modélisées ou générées. En psychologie, un archétype est le modèle d'une personne, d'une personnalité ou d'un comportement. [5]

Dans toute organisation de moyenne à grande échelle, les tâches sont affectées à différentes personnes, en fonction de leurs responsabilités dans l'organisation. En général, les analystes métier et les applications métier doivent protéger les actifs en informations de l'entreprise. Ils pilotent la création des exigences des applications métier pour la sécurité.

Archétype 1 - Analyste métier

Les organisations devant se conformer à des exigences législatives ou réglementaires prévoient parfois un ensemble spécifique de tâches au niveau "C" afin de surveiller et de mettre en oeuvre ces réglementations. Le responsable de la sécurité (CSO - Chief Security Officer) et le responsable de la confidentialité (CPO - Chief Privacy Officer) collaborent généralement avec les analystes métier afin de compiler un ensemble d'instructions et d'exigences propres à l'entreprise, à savoir les bases des pratiques métier d'excellence.

Archétype 2 - Responsable de la sécurité (de la confidentialité)

La plupart des organisations, quelle que soit leur taille, possèdent aujourd'hui un pare-feu. Les utilisateurs individuels établissent, à leur domicile, un pare-feu pour leur réseau domestique. Ces dispositifs doivent être configurés et gérés. Certains sont simples, d'autres sont plus complexes.

Archétype 3 - Responsable de la sécurité du réseau

Lorsqu'il s'agit de comprendre et de sélectionner un type de mécanisme de sécurité afin de répondre aux exigences de l'entreprise, plusieurs personnes travaillent de concert pour mettre en oeuvre la sécurité.  

Archétype 4 -  Architecte de sécurité

Security Developer, Security Deployer, Security Policy Author, Security Policy Administrator, Security System Adminstrator

Observation des patterns par rôle

L'objectif du présent document et du module de diapositives associé est de fournir une ossature qui permet d'identifier et d'illustrer des patterns de sécurité communs existants, au sein de la communauté des analystes métier, clients d'IBM. La tâche de l'effort d'élaboration de patterns e-business consiste à regrouper le volume d'informations en une abstraction assez générale pour pouvoir être utilisée par des spécialistes dans d'autres domaines que la sécurité tout en conservant un contexte suffisant pour fournir des bases concrètes à la communauté des experts en sécurité.

IBM est un microcosme de l'industrie du développement de logiciels car cette entreprise représente à la fois le développement de produits et le développement de services d'application métier ainsi que les produits intermédiaires pour la gestion et le déploiement d'applications. 

Il existe plusieurs méthodologies permettant de concevoir et de développer des applications sécurisées (c'est-à-dire, MASS, Open Group, JAAS) mais un grand nombre est destiné aux professionnels chevronnés en sécurité ayant une parfaite compréhension de la technologie. Ainsi, un groupe de patterns peut être "patterns d'architecture de sécurité". Des architectures détaillées sont nécessaires pour développer la technologie fournissant des solutions de sécurité et ces architectures sont mentionnées par les patterns le cas échéant, mais le présent document n'est pas destiné à documenter tous les patterns d'architecture de sécurité.

Qu'est-ce que la sécurité ?

Le groupe de travail IETF est une organisation qui a joué un rôle fondamental dans le développement d'Internet tel que nous le connaissons aujourd'hui. En 2000, le groupe de travail IETF a établi un glossaire relatif à la sécurité qui contient la plupart des concepts fondamentaux de la sécurité informatique. Des améliorations sont apportées, des technologies et des mécanismes apparaissent et disparaissent mais les définitions élémentaires demeurent.

Les composants les plus couramment utilisés aujourd'hui dans le domaine de la sécurité sont les suivants : identification et authentification, autorisation, assurance, audit, protection des messages, confidentialité, intégrité. Plutôt que de fournir uniquement des patterns pour chaque mécanisme de sécurité, le présent livre blanc a examiné l'ensemble des mécanismes de sécurité afin d'en identifier les caractéristiques communes. Ce livre blanc met l'accent sur l'identification d'un "pattern de solution de sécurité". Ces éléments communs ont été créés à partir de l'observation d'un ensemble détaillé d'éléments de pattern individuels pour chaque mécanisme de sécurité (c'est-à-dire le mécanisme d'authentification comporte les éléments nom d'utilisateur, mot de passe, Kerberos, indicateur clé de performances), puis en faisant abstraction de ces éléments communs entre l'authentification, l'autorisation, l'assurance, etc.

La recherche d'éléments communs dans tous les patterns de sécurité a entraîné l'identification des trois sous-éléments de pattern présents dans un format donné dans tout type de solution de sécurité :

  1. à une étape donnée de l'exécution du logiciel, le mécanisme de sécurité doit être appelé (c'est-à-dire à un "point de contrôle")
  2. il existe généralement un type de méta-informations important pour l'exécution du point 1 et désigné par l'expression "propriétés d'accès et d'accréditation au système"
  3. une tâche est liée à l'initialisation et à la maintenance permanente du mécanisme de sécurité ; ce type de tâche est désigné par l'expression "tâches de gestion de la sécurité/d'enchaînement des activités".

Présentation des patterns de sécurité

L'exemple d'"identification" démontre comment chaque mécanisme de sécurité peut être mappé sur ces trois sous-éléments. Extrait du glossaire du groupe de travail IETF :

identification - (I) Action ou processus présentant un identificateur à un système afin que le système puisse reconnaître une entité système et la distinguer d'autres entités (voir : authentification). 

Distinguer une personne d'une autre lors de l'appel d'une application est un pattern auquel est confrontée toute entreprise. Les stratégies permettant de résoudre l'incident métier varient en fonction du nombre et de la diversité des éléments impliqués dans l'application et dans son environnement de déploiement. Certaines entreprises laissent la décision de la "désignation" à chaque application ou à un groupe d'applications dans un secteur d'activités. Certaines entreprises sont limitées par les logiciels de leurs centres de données. D'autres ont étroitement lié l'environnement de déploiement d'application à un ensemble strict de mécanismes.  

Il existe néanmoins un point où un "identificateur" est présenté à une application et cela est considéré comme un pattern de "point de contrôle de sécurité", pour identification. La quantité et le type des informations requises varient aussi considérablement. Un identificateur peut être le nom d'une personne réelle (c'est-à-dire Maryann Hondo) ou un pseudonyme (par exemple, mhondo). L'identificateur peut être un identificateur unique universel (UUID) ou il peut être unique au sein d'un espace de nom qualifié (c'est-à-dire mhondo@us.ibm.com).

Caractéristiques d'un pattern de sécurité

  • Définition d'un ou plusieurs points de contrôle (identité, authentification, autorisation, mise en application de règles, audit, conformité, protection des messages)
  • Définition de propriétés de protection de système (contraintes de configuration ; règles d'accès et d'accréditation)
  • Définition de tâches de gestion (application des accès, synchronisation des registres/référentiels, gouvernance, surveillance)

Références

  1. RFC 2828 Internet Security Glossary May 2000
  2. Understanding and Using Patterns in Software Development, Dirk Riehle et Heinz Zullighoven.
  3. Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides.
  4. Patterns and Software: Essential Concepts and Terminology, Brad Appleton : http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html#Origins
  5. Wikipedia : http://en.wikipedia.org/wiki/Archetype