c'est un organisme indépendant qui effectue l'évaluation.
Il y a plusieurs modes de certification (ITSEC, CC) et chaque pays à un organisme chargé de délivré des certifications (en France la DCSSI).
Le demandeur choisi un niveau de certification souhaité (EAL2+ pour Linux chez Suse par ex) et plus le niveau est élevé, plus la rigueur d'analyse des mécanismes de sécurité sera importante : c'est l'évaluation qui n'est pas réalisé par l'organisme certificateur mais par un tiers indépendant (en France , les CESTI cf http://www.ssi.gouv.fr(...)). De plus, la certification porte souvent sur une sous-partie du produit : c'est la cible d'évaluation. Cela regroupe ce qui est analysé et en regardant ce document qui est public, on peut voir que des coupes sont souvent effectuées. Ensuite dans le certificat, il y a des conditions d'emploi nécessaire au fonctionnement en mode "certifié" : par exemple Windows NT4 était certifié mais en standalone (sans réseau). Pour Win2K ce n'est plus le cas, mais tout çà pour dire que la certification en elle-même c'est bien mais il y a des détails à regarder pour évaluer la confiance que l'on peut avoir en un produit (cible et contraintes d'utilisation).
En schématisant, pour un bas niveau, une simple doc commerciale pourrait suffire et pour les niveaux élevés, il faut des preuves formelles (modèle mathématique, etc...). Pour le logiciel, les hauts niveaux sont très difficiles car on tire bcp de dépendances qu'on ne maîtrise pas (librairie C par exemple) et qu'on ne sait modéliser.
Bref, plus on monte dans les niveaux, plus on doit affiner la présentation des dispositifs de sécurité en énumérant les risques auxquelles ils peuvent être confrontés et les contre mesures mises en oeuvre. Et si tout çà est cohérent et que le produit résiste aux attaques "état de l'art", on le certifie.
Mais le certificat est valable un jour et il ne prémunit pas contre la découverte de nouvelles failles. Pour le logiciel, une analyse rigoureuse du code source peut être effectuée dans des niveaux élevés de certification. Or, Win2k n'est pas certifié à un tel niveau, donc on ne peut garantir l'absence de failles type buffer overflow par exemple. Par contre, on sait que l'authentification çà marche comme çà et que c'est robuste (syskey par exemple), pareil pour d'autres éléments de sécurité.
Le fait que Linux soit à un niveau inférieur à Win2k ne veut pas dire qu'il est moins bon. Mais la certification c'est compliqué et on ne se lance pas bille en tête dans une évaluation haut niveau (çà coûte cher). Donc Suse commence EAL2 puis il vont monter les niveaux
(cf. http://www.suse.com/en/company/press/press_releases/archive03/secur(...))
vers EAL3 et on verra après.
Au fait, ils font çà parce qu'une loi ou directive est passée aux Etats Unis qui oblige à présenter des produits certifiés pour fournir la défense ou tout les ministères (je sais plus trop bien).
[^] # Re: Linux et IBM recoivent un satisfecit de Washington
Posté par jojo2002 . En réponse à la dépêche Linux et IBM reçoivent un satisfecit de Washington. Évalué à 6.
Il y a plusieurs modes de certification (ITSEC, CC) et chaque pays à un organisme chargé de délivré des certifications (en France la DCSSI).
Le demandeur choisi un niveau de certification souhaité (EAL2+ pour Linux chez Suse par ex) et plus le niveau est élevé, plus la rigueur d'analyse des mécanismes de sécurité sera importante : c'est l'évaluation qui n'est pas réalisé par l'organisme certificateur mais par un tiers indépendant (en France , les CESTI cf http://www.ssi.gouv.fr(...)). De plus, la certification porte souvent sur une sous-partie du produit : c'est la cible d'évaluation. Cela regroupe ce qui est analysé et en regardant ce document qui est public, on peut voir que des coupes sont souvent effectuées. Ensuite dans le certificat, il y a des conditions d'emploi nécessaire au fonctionnement en mode "certifié" : par exemple Windows NT4 était certifié mais en standalone (sans réseau). Pour Win2K ce n'est plus le cas, mais tout çà pour dire que la certification en elle-même c'est bien mais il y a des détails à regarder pour évaluer la confiance que l'on peut avoir en un produit (cible et contraintes d'utilisation).
En schématisant, pour un bas niveau, une simple doc commerciale pourrait suffire et pour les niveaux élevés, il faut des preuves formelles (modèle mathématique, etc...). Pour le logiciel, les hauts niveaux sont très difficiles car on tire bcp de dépendances qu'on ne maîtrise pas (librairie C par exemple) et qu'on ne sait modéliser.
Bref, plus on monte dans les niveaux, plus on doit affiner la présentation des dispositifs de sécurité en énumérant les risques auxquelles ils peuvent être confrontés et les contre mesures mises en oeuvre. Et si tout çà est cohérent et que le produit résiste aux attaques "état de l'art", on le certifie.
Mais le certificat est valable un jour et il ne prémunit pas contre la découverte de nouvelles failles. Pour le logiciel, une analyse rigoureuse du code source peut être effectuée dans des niveaux élevés de certification. Or, Win2k n'est pas certifié à un tel niveau, donc on ne peut garantir l'absence de failles type buffer overflow par exemple. Par contre, on sait que l'authentification çà marche comme çà et que c'est robuste (syskey par exemple), pareil pour d'autres éléments de sécurité.
Le fait que Linux soit à un niveau inférieur à Win2k ne veut pas dire qu'il est moins bon. Mais la certification c'est compliqué et on ne se lance pas bille en tête dans une évaluation haut niveau (çà coûte cher). Donc Suse commence EAL2 puis il vont monter les niveaux
(cf. http://www.suse.com/en/company/press/press_releases/archive03/secur(...))
vers EAL3 et on verra après.
Au fait, ils font çà parce qu'une loi ou directive est passée aux Etats Unis qui oblige à présenter des produits certifiés pour fournir la défense ou tout les ministères (je sais plus trop bien).