Dans mon précédent billet, il fut question d’introduire et de présenter le concept de dépérimétrisation en matière de sécurité du Système d’Information de l’entreprise. A titre de rappel, la dépérimétrisation est la tendance technologique qui veut que les principaux Intervenant sur le Système d’Information de l’entreprise ne soit plus tous lotis dans le périmètre de sécurité (généralement physique) prédéfini ; il devient alors nécessaire de pourvoir assurer la disponibilité, la confidentialité et l’intégrité de ses informations en cours transit dans différents terminaux et infrastructures dont l’entreprise ne possède pas généralement la maîtrise complète.

Ce Second billet sera principalement basé sur les 11 Commandements définis par le groupe de travail JERICHO FORUM qui ouvre essentiellement pour la mise en place d’un Framework de principes pour accompagner les entreprises dans leur projet de dépérimétrisation. Ces 11 directives, ainsi qu’une brève explication de chacune d’elle, sont définies plus bas.

1- L’étendu et le niveau de protection doit être proportionnel au risque que représente l’actif.

Pour l’Entreprise, la Sécurité doit prendre en compte l’agilité de ses différents Métiers et être aussi rentable. Par ailleurs les pare feu et autres IDS/IPS doivent continuer à assurer la protection du réseau de l’entreprise car bien que parfois limités, ils permettent tout même de contenir certains types d’attaques. De plus, les Systèmes isolés ainsi que les données  doivent intégrer des mécanismes de protection inhérents de façon à pouvoir s’autogérer bien qu’étant coupé du reste du réseau.

2- Les mécanismes de sécurité doivent être omniprésents, simples, évolutifs et faciles à gérer.

Les complexités superflues pouvant finir par être des obstacles à l’adoption et la mise en œuvre des procédures de sécurité, il convient de s’en abstenir tant que possible. De plus, la stratégie de sécurité mise en place doit pouvoir épouser et se fondre dans les différents tiers de l’architecture du Système d’Information de l’Entreprise. Il en est de même que ces mesures doivent être suffisamment granulaires et évolutives afin de prendre en compte les besoins actuels et futurs de chaque couche de protection tout en restant uniforme.

3- Prendre en compte le contexte à vos risques et périls.

Les Polices et Solutions de sécurité conçues pour un environnement donné ne sont pas nécessairement applicables dans un autre environnement et ceci pour une variété de raisons qui peuvent  être d’ordre géographique, juridique, technique, acceptabilité du risque, etc. Ainsi, il est important de comprendre les limites et conditions d’usage de toute mesure de sécurité avant de l’adopter dans chaque environnement.

4- Les équipements et les applications doivent communiquer en utilisant des protocoles ouverts et sécurisés.

La sécurité par l’obscurité a suffisamment montré ses limites – des protocoles sécurisés et  ouverts permettrons un examen par les pairs afin de fournir une évaluation robuste et une plus large acceptation et utilisation. Les exigences de sécurité de la confidentialité, de l’intégrité et de la disponibilité doivent être évalué et intégré à des protocoles au besoin et non simplement ajoutés sous forme de surcouche logicielle.

5- Tous les appareils doivent être capables de maintenir leur politique de sécurité sur un réseau de  « non-confiance ».

Les règles de sécurité doivent être respectée et applicables quel que soit le contexte où se trouve l’équipement à un moment donné.

6- Toute personne, processus et technologie doit  avoir un niveau d’approbation déclaré et transparent avant que toute transaction puisse avoir lieu.

L’Approbation dans ce contexte est établie par la compréhension entre les parties prenantes à la transaction et la satisfaction de chacune aux obligations qui lui incombent.  Les modèles d’approbations doivent comprendre les personnes et organisations ainsi que les périphérique et l’Infrastructure.  Bien entendu, le Niveau d’approbation peut varier selon l’emplacement, le type de transaction, le rôle de l’utilisateur, et le risque transactionnel.

7- L’assurance d’un niveau d’Approbation mutuel doit être identifiable.

Les utilisateurs et les périphériques doivent être capables de satisfaire de façon mutuelle au niveau d’exigence d’authentification pour avoir accès aux Systèmes ainsi qu’aux données de l’Entreprise.

8- Authentification, l’Autorisation et la Responsabilité doivent inter opérer / échanger en dehors de votre zone de contrôle.

Les personnes et systèmes doivent être en mesure de gérer les permissions sur les ressources et les droits des utilisateurs qu’ils ne contrôlent pas.  L’ensemble doit  permettre l’établissement d’une relation d’approbation avec une organisation, pouvant ainsi authentifier les utilisateurs ou groupes sans pour autant nécessiter la création d’identités distinctes. Les systèmes doivent être en mesure de transmettre les informations d’identification de sécurité.

9- L’accès aux données doit être contrôlé par des attributs de sécurité intégrés dans les données elles-mêmes.

Les attributs peuvent être intégrés dans les données (DRM / métadonnées) ou pourraient être un système séparé à part entière. La sécurité peut être implémentée à ce niveau via un chiffrage. Les accès ainsi que les privilèges d’accès doivent intégrer une composante temporelle, ceci afin de palier à certains cas de vols de session et d’identité.

10- Les DOnnées Confidentielles (et la protection d’un actif de valeur suffisamment élevée) nécessitent une la séparation des tâches et privilèges.

Les Autorisations, les clés de chiffrement, les privilèges d’accès, etc doivent être sous un contrôle indépendant, sinon on court le risque d’avoir un maillon faible dans la partie supérieure de la chaîne de confiance (ce qui est, malheureusement, très souvent le cas). Les accès administrateurs ne sont pas exempts de ces contrôles

11- Par défaut, les données doivent être bien protégées lorsqu’elles sont stockées, en transit, et en cours d’utilisation.

La modification de ce standard par défaut est réservée pour ceux qui savent ce qu’ils font. Un niveau de sécurité accru ne doit pas être appliqué à tout, il est important de jauger le niveau de risque avant d’y adapter un niveau de sécurité, et partant de ce principe on peut aussi bien se retrouver avec des données pas du tout sécurisées !

Notons que tout ce qui est défini plus haut ne se réalisera pas du jour au lendemain. Ces Commandements sont une feuilles de route à suivre pas à pas afin d’arriver à un Système d’Information Sécurisé et capable de survivre aux différents changements et évolutions que nous réserve le temps, et dont certains sont même déjà en cours au sein de nos Entreprises.

Vous trouverez la version originale des commandement du Jericho Forum sur la dépérimétrisation ici (en Anglais).

Valdes T. Nzalli

Site Web Jericho Forum