En parlant de source, tu en as une pour cette affirmation ?
J'ai participé à quelques évaluations CSPN, et il me semblait que c'était obligatoire, alors qu'il semble que en effet ce ne soit pas le cas. Cela dit cela permet de réduire le nombre de jours de l'évaluation et donc le coût de la CSPN.
Donc, on n’attend de la revue de code (quand elle a lieu) ni qu’elle soit exhaustive (l’évaluateur peut ne regarder qu’une partie des modules), ni qu’elle ne cherche des failles ou des vulnérabilités.
Tout à fait, une CSPN vise à vérifier que les fonctions de sécurité du produit sont respectée (la cible est tut de même validée par l'ANSSI, et une cible qui ne couvre pas correctement les fonctionalités du produit peut être refusée). Par exemple si il y a du chiffrement la CSPN t'assure que les bonnes pratiques sont utilisées : des algos pas vulns, les bonnes tailles de clés, etc. Mais pas qu'il n'y a pas un use-after-free enfoui quelque part dans l'implementation du chiffrement.
Le code est quand même utile pour l'évaluation. Par exemple si il faut étudier comment sont stockées des données confidentitelles, c'est plus pratique avec le code. Pour autant, il ne s'agit pas d'un audit de code visant à trouver des vulnérabilités.
Cela dit si l'auditeur reporte des vulnérabilités (par exemple SQLi évidentes sur un webservice) cela est pris en compte pour l'évaluation.
[^] # Re: Une honte
Posté par brendel . En réponse à la dépêche Tixeo, une solution propriétaire de visioconférence sécurisée sous GNU/Linux. Évalué à 2.
J'ai participé à quelques évaluations CSPN, et il me semblait que c'était obligatoire, alors qu'il semble que en effet ce ne soit pas le cas. Cela dit cela permet de réduire le nombre de jours de l'évaluation et donc le coût de la CSPN.
Tout à fait, une CSPN vise à vérifier que les fonctions de sécurité du produit sont respectée (la cible est tut de même validée par l'ANSSI, et une cible qui ne couvre pas correctement les fonctionalités du produit peut être refusée). Par exemple si il y a du chiffrement la CSPN t'assure que les bonnes pratiques sont utilisées : des algos pas vulns, les bonnes tailles de clés, etc. Mais pas qu'il n'y a pas un use-after-free enfoui quelque part dans l'implementation du chiffrement.
Le code est quand même utile pour l'évaluation. Par exemple si il faut étudier comment sont stockées des données confidentitelles, c'est plus pratique avec le code. Pour autant, il ne s'agit pas d'un audit de code visant à trouver des vulnérabilités.
Cela dit si l'auditeur reporte des vulnérabilités (par exemple SQLi évidentes sur un webservice) cela est pris en compte pour l'évaluation.