Les extensions de sécurité d’UNIX

Si la sécurité d’UNIX n’est pas
suffisante pour satisfaire les exigences de votre entreprise, il y a
des produits supplémentaires pour rendre UNIX plus sécurité.
De plus, vous pouvez employer une des versions d’UNIX pour lesquelles
1’architecture a été repensée, pour qu’UNIX
respecte les critères de sécurité du
gouvernement. Adopter aux USA et dans la Communauté
Européenne, ces critères mesurent la sécurité
des systèmes d’ordinateurs ainsi, ils peuvent être
certifies par le gouvernement.

Le paragraphe suivant introduit les critères
de sécurité Américains et Européens et
donne un aperçu des extensions et des alternatives a l’Unix
standard qui accroissent la sécurité du système.

Choisir des systèmes sécurités

Vous pouvez consulter les critères du
gouvernement pour commencer à vous familiariser avec les
alternatives ou les extensions de sécurité au système
UNIX standard qui pourraient s’appliquer aux exigences de sécurité
de votre entreprise. Les critères de sécurité
incluent l’information fondamentale concernant quelle fonctionnalité
de sécurité est efficace contre quelle menace de
sécurité En dormant des critères de sécurité,
vous pourrez choisir la fonctionnalité de sécurité
qui correspond à vos exigences de sécurité Les
évaluations du produit peuvent vous donner 1’information sur
le marché pour des systèmes qui correspondent bien à
vos besoins. Les deux plus importants critères de sécurité
sont introduits ci-dessous.

Les critères de sécurité US : TCSEC

L’armée a été la première
à reconnaître le problème de sécurité
des systèmes d’ordinateurs. En 1983 aux USA, le ’Department of
Defense’ (Département de la Défense) publiait une étude
qui définissait les exigences générales pour la
sécurité de l’information dans les systèmes
d’ordinateurs : Department of Defense Trusted Computer System
Evaluation Criteria (TCSEC). La couleur de sa couverture l’a conduit
à être appelé communément l’Orange Book

Les critères de 1’Orange Book catégorisent
les systèmes d’ordinateurs évalués Dans quatre
groupes avec des niveaux A, B, C et D. Les groupes forment une
hiérarchie d’exigences de sécurité Le groupe A
inclut les exigences les plus hautes de sécurité, D les
plus basses. Dans les groupes B et C, il y a une subdivision en
classes qui sont aussi ordonnées hiérarchiquement.
Chaque niveau de sécurité inclut les exigences de
sécurité décrites ci-dessous.

Les classes sont définies comme suit :

D : La protection minimale

Cette classe inclut tour les systèmes qui
n’ont pas de mécanismes logiciels de sécurité

C1 : La protection de sécurité discrétionnaire

C1 requiert que les utilisateurs soient capables
d’établir et de changer 1’accessibilite à
leurs objets. Ces privilèges d’accès sont bases
sur trois catégories : l’utilisateur propriétaire, les
membres du groupe et les autres. En outre, le système requiert
que les utilisateurs soient autorises à
s’identifier eux-mêmes par un nom d’utilisateur et un
mot de passe (Discretionary Access Control, DAC).

C2 : La protection par contrôle des accès

C2 requiert davantage de protection d’accès
que les systèmes certifies C1. Les utilisateurs de systèmes
C2 peuvent entre tenus responsables de leurs actions. Dans ce but,
les systèmes C2 ont une procédure de connexion, une
procédure d’audit de la sécurité du système
et une protection du noyau du système (Trusted Computer Base,
TCB )

B1 : La protection de sécurité par tickets

B1 contient une protection de contrôle d’accès
obligatoire (Mandatory Access Control, MAC), qui dicte quels
utilisateurs ont les permissions d’accéder à
quels objets. Dans ce but, utilisateurs et objets doivent
donner leur identification de sécurité, appelée
’tickets’’. Les tickets des objets contiennent un niveau de sécurité
tel que ’confidentiel, ’très confidentiel, ’secret’, ’top
secret’. Les tickets des utilisateurs contiennent une catégorie
indiquant l’autorité de l’utilisateur.

B2 : La protection structurée

En plus du MAC, B2 requiert un modèle formel
de sécurité de système. II doit être
prouvé que le transfert indirect d’informations non autorisées
n’est pas possible.

B3 : Les domaines sécurités

B3 requiert l’isolement en domaines surs du matériel
utilise par le système. Tout accès à
un objet est contrôlé et enregistré par un
’moniteur de référence’. Un chemin approuvé
assure qu’un utilisateur, par son terminal, est directement en
communication avec le système. Cela empêche un programme
’mystificateur’ de lire le mot de passe entre par l’utilisateur et
permettre l’entrée d’un intrus potentiel.

A1 : Conception vérifiée

Pour les systèmes Al, une preuve mathématique
formelle est nécessaire. Elle doit prouver l’exactitude
théorique du module de sécurité sur lequel
l’architecture du système est basée. L’autre exigence
consiste à démontrer qu’aucune
transmission non autorisée d’informations (canal sécurisé)
ne peut survenir.

Les critères de sécurité européens : ITSEC

La Communauté Européenne de sécurité
publie des critères de sécurité pour les
logiciels et systèmes qui supplantent les critères de
sécurité des nations Britannique, Allemande,
Hollandaise et Française. Les critères de sécurité
Européens sont appelés ’Information Technology Security
Evaluation Criteria’ (ITSEC). Ils évaluent la sécurité
des produits et des systèmes (désignes sous le nom de
’Target Of Evaluation’ ou TOE) selon deux catalogues de critères
L’un évalue l’exactitude de la mise en oeuvre, l’autre
l’efficacité de la fonctionnalité de la sécurité
La classification, pour l’exactitude, organise les TOE en sept
classes, dans lesquelles E0 est la plus basse et E6 la classe la plus
haute. La classification, pour les fonctionnalités F-C1 à
F-B3 est dérive de l’Orange Book et correspond aux
fonctionnalités de la sécurité des niveaux C1 à
A1. ,

Le schéma ci-après montre la
correspondance des classes entre l’Orange Book et l’ITSEC

La sécurité au Canada

Le gouvernement canadien a entrepris de concevoir
ses propres standards de sécurisation de 1’informatique pour
le Canada. Ces standards possèdent deux composantes
principales : les CTCPEC (Canadian Trusted Computer Product
Evaluation Criteria) et les critères communs (Common
Criteria).

Les CTCPEC concernent a la fois les fonctionnalités
et la fiabilité du produit en cours de développement ou
d’évaluation. Les fonctionnalités incluent les
questions de confidentialité, d’intégrité, de
disponibilité et de sûreté. La fiabilité
concerne le degré de confiance que 1’on peut accorder a un
produit dans sa mire en oeuvre de la politique de sécurité
d’une entreprise.

Les critères communs résultent d’un
effort de collaboration pour rassembler les recherches effectuées
aux États-Unis, Canada, France, Allemagne et Royaume-Uni. Ce
document contient les conditions de sélection des mesures de
sécurité en matière d’ informatique.

Il y a sept niveaux de fiabilité dans les
critères communs : EAL-1 a EAL-7. Vous trouverez leurs
descriptions dans les sections suivantes.

Niveau EAL-1

EAL-1 est le plus bas niveau de fiabilité
significatif pour le développeur et 1’acquereur. Il est défini
à ce niveau à partir d’une analyse des fonctions
inhérentes à la sécurité du produit au
niveau de la conception fonctionnelle et des interfaces, telles
qu’elles sont présentées par le développeur,
pour une meilleure compréhension du comportement sécuritaire.

Niveau EAL-2

EAL-2 est le niveau le plus élevé de
fiabilité qu’il est possible d’obtenir sans imposer au
développeur du produit des taches supplémentaires par
rapport à celles requises par EAL-1. Une analyse des
spécifications fonctionnelles et d’interface est faite,
accompagnée d’un contrôle de conception de haut niveau
sur les sous systèmes.

Niveau EAL-3

EAL-3 décrit un niveau de sécurité
relativement modeste valide par une source extérieure. Ce
niveau permet une fiabilité maximum depuis le stade de la
conception, avec peu de modifications dans le processus de test.
Cette fiabilité maximum implique que le produit ait été 
conçu au départ sous l’angle de la sécurité,
à la différence d’une mise en oeuvre postérieure
à la conception du produit. Le développeur doit prouver
qu’il a effectué les tests requis en fournissant des analyses
de vulnérabilité, qui seront vérifiées
sélectivement. Il s’agit également du premier niveau à
comporter des critères d’évaluation de la gestion de la
configuration.

Niveau EAL-4

EAL-4 est le plus haut niveau de fiabilité 
réalisable à posteriori sur une ligne de produits
existants. Un produit équipé d’un niveau d’assurance
EAL-4 est méthodiquement conçu, teste et vérifie,
ce qui fournit à son acquéreur un niveau de sécurité
maximum sur la base de logiciels de développement du commerce
simples à utiliser. L’utilisation de ces pratiques permet
d’évacuer les problèmes habituels de conception
logicielle pouvant miner un projet.

Outre les éléments du niveau EAL-3, la
mise en oeuvre du niveau EAL-4 comporte une recherche extérieure
des points vulnérables d’un produit.

Niveau EAL-5

EAL-5 n’est pas simple à mettre en place sur
les produits existants, car ceux-ci doivent être conçus
et construits avec 1’intention a priori de les mettre en place. En
effet, l’équipe de développement doit concevoir des
applications basées sur des logiciels de marché et
utiliser des techniques d’ingénierie. Ce niveau convient aux
développeurs et utilisateurs qui ont un besoin élevé
de fiabilité découlant d’une approche rigoureuse de la
programmation. A ce niveau, le développeur doit expliquer les
spécifications de la conception et comment celles-ci sont
mises en oeuvre au niveau fonctionnel.

Niveau EAL-6

EAL-6 consiste en une composante de test et do
conception vérifiée semi-formelle. Ce niveau comporte
tous les critères de EAL-5, assortis de 1’exigence d’une
présentation structurée de la mise en oeuvre. En outre,
le produit subit un contrôle de conception simple puis étendu
et doit assurer une grande capacité de résistance aux
attaques. Le niveau EAL-6 requiert également la mise en place,
tout au long du cycle de conception, d’un processus de développement
structure et de contrôle de gestion de la configuration.

Niveau EAL-7

EAL-7 ne convient qu’au niveau le plus élevé
des applications de sécurité, lorsque les risques
majeurs et autres brèches justifient le coût du
développement et par conséquent, le prix pays par
1’acquéreur. Ce niveau consiste en un contrôle de
conception complet, extérieur et formel, assorti d’étapes
de vérification de la conception vérifiée et de
tests. Le développeur doit tester chaque facette du produit, à
la recherche de points vulnérables évidents ou pas, qui
seront ensuite vérifies entièrement par une source
extérieure. Ce processus va jusque dans les moindres détails
et le bureau dévaluation doit être impliqué
depuis la conception de 1’idée jusqu’à 1’achèvement
du produit.