C I B L E D E S É C U R I T É
Firewalls NETASQ
Évaluation de la suite logicielle
IPS-Firewall Version 5
Évaluation selon un paquet EAL2 augmenté des
Critères Communs V2.2
C I B L E D E S É C U R I T É
SUIVIE DE DOCUMENT
Version Auteur Date Modifications
0.1 Boris Maréchal 27/04/04 Version initiale du document
1.0 Boris Maréchal 05/05/04 Intégration remarques et références
1.1 Boris Maréchal 29/06/04 Intégration remarques initiales d'AQL
1.2 Boris Maréchal 10/09/04 Intégration remarques FdC01 et FdC02 du
CESTI AQL
1.3 Boris Maréchal 20/09/04 Passage à la version 5.1 de la TOE
1.4 Boris Maréchal 17/11/04 Ajout droit sur base de temps
1.5 Boris Maréchal 10/12/04 Passage à la version 5.1.2 de la TOE
1.6 Boris Maréchal 03/03/05 Passage à la version 5.1.4 de la TOE
1.7 Boris Maréchal 07/03/05 Retrait de MD5, RSA et DH en 1024b (bureau
crypto)
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 2 de 109 Référence : na_tn_ciblesec_fr.sxw
C I B L E D E S É C U R I T É
TABLE DES MATIÈRES
1INTRODUCTION....................................................................................................................................7
1.1Identification de la cible de sécurité............................................................................................7
1.2Annonces de conformité...............................................................................................................7
1.3Résumé des fonctionnalités du firewall-VPN NETASQ.............................................................7
1.4Documents applicables et de référence......................................................................................8
1.4.1Référentiel des Critères Communs......................................................................................8
1.4.2Schéma Français d’Évaluation et de Certification.............................................................8
1.4.3RFC et autres standards.......................................................................................................8
1.5Glossaire.......................................................................................................................................
10
2DESCRIPTION DE LA CIBLE D’ÉVALUATION..................................................................................13
2.1Caractéristiques de sécurité TI de la TOE.................................................................................13
2.1.1Généralités............................................................................................................................
13
2.1.2Le contrôle des flux d’information.....................................................................................13
2.1.3La protection contre les attaques Internet........................................................................14
2.1.4Les risques d’utilisation impropre.....................................................................................15
2.1.5La protection de la TOE elle-même....................................................................................16
2.2Limites physiques de la TOE......................................................................................................17
2.2.1Équipements constituant la TOE.......................................................................................17
2.2.2Caractéristiques minimum des plates-formes d’exploitation.........................................18
2.3Limites logiques de la TOE.........................................................................................................19
2.3.1Composants logiciels..........................................................................................................19
2.3.2Architecture et interfaces de la TOE..................................................................................19
2.3.3Configurations et modes d’utilisation soumis à l’évaluation..........................................20
2.4Plate-forme de test utilisée lors de l’évaluation.......................................................................21
3ENVIRONNEMENT DE SÉCURITÉ DE LA CIBLE D’ÉVALUATION..................................................22
3.1Identification des biens sensibles.............................................................................................22
3.1.1Biens protégés par la TOE..................................................................................................22
3.1.2Biens appartenant à la TOE................................................................................................22
3.2Menaces et règles de la politique de sécurité..........................................................................23
3.2.1Le contrôle des flux d’information.....................................................................................23
3.2.2La protection contre les attaques Internet........................................................................23
3.2.3Les risques d’utilisation impropre.....................................................................................24
3.2.4La protection de la TOE elle-même....................................................................................24
3.3Hypothèses...................................................................................................................................
25
3.3.1Hypothèses sur les mesures de sécurité physiques.......................................................25
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 3 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
3.3.2Hypothèses sur les mesures de sécurité organisationnelles.........................................25
3.3.3Hypothèses relatives aux agents humains.......................................................................26
3.3.4Hypothèses sur l’environnement de sécurité TI...............................................................26
4OBJECTIFS DE SÉCURITÉ.................................................................................................................27
4.1Généralités...................................................................................................................................27
4.2Objectifs de contrôle des flux d’information............................................................................28
4.3Objectifs de protection contre les attaques Internet...............................................................30
4.4Objectifs de prévention de l’utilisation impropre.....................................................................31
4.5Objectifs de protection de la TOE..............................................................................................32
4.6Autres objectifs de soutien des mesures d’assurance sécurité............................................ 32
4.7Objectifs de sécurité pour l’environnement.............................................................................33
4.8Argumentaire des objectifs de sécurité....................................................................................35
5EXIGENCES DE SÉCURITÉ DES TI...................................................................................................37
5.1Introduction..................................................................................................................................37
5.1.1Généralités............................................................................................................................
37
5.1.2Conventions typographiques.............................................................................................37
5.1.3Présentation des données de sécurité..............................................................................38
5.2Exigences de sécurité pour la TOE...........................................................................................42
5.2.1Exigences de contrôle des flux d’information..................................................................42
5.2.2Exigences de protection contre les attaques Internet.....................................................49
5.2.3Exigences de prévention de l’utilisation impropre...........................................................50
5.2.4Exigences de protection de la TOE....................................................................................53
5.2.5Autres exigences de sécurité de soutien..........................................................................54
5.3Exigences d’assurance sécurité pour la TOE...........................................................................56
5.3.1Autres mesures d’assurance sécurité...............................................................................56
5.4Exigences de sécurité pour l’environnement TI.......................................................................60
5.5Argumentaire des exigences de sécurité..................................................................................60
5.5.1Satisfaction des objectifs de sécurité...............................................................................60
5.5.2Cohérence de la résistance des fonctions de sécurité avec les objectifs de sécurité.61
5.5.3Soutien mutuel et non contradiction.................................................................................61
5.5.4Satisfaction des dépendances...........................................................................................62
6SPÉCIFICATIONS ABRÉGÉES DE LA TOE.......................................................................................66
6.1Fonctions de sécurité des TI......................................................................................................66
6.1.1Fonctions de filtrage............................................................................................................66
6.1.2Fonctions d’identification / authentification.....................................................................67
6.1.3Fonctions de chiffrement....................................................................................................68
6.1.4Fonctions d’établissement des SA....................................................................................70
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 4 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
6.1.5Fonctions de journalisation, d’audit et d’alarme..............................................................74
6.1.6Fonctions de programmation horaire................................................................................75
6.1.7Fonctions de prévention des intrusions...........................................................................76
6.1.8Fonctions de contrôle d’accès aux opérations d’administration de la sécurité...........76
6.1.9Fonctions de sauvegarde et de restauration....................................................................77
6.1.10Fonctions de protection des sessions d’administration...............................................77
6.1.11Autres fonctions de soutien.............................................................................................79
6.2Mesures d’assurance sécurité...................................................................................................80
6.2.1Mesures de l’environnement de développement..............................................................80
6.2.2Documentation et outils de développement des fonctions de sécurité........................ 81
6.2.3Test des fonctions de sécurité...........................................................................................81
6.2.4Documentation d’exploitation............................................................................................82
6.2.5Estimation de la vulnérabilité.............................................................................................83
6.3Argumentaire des spécifications abrégées de la TOE.............................................................84
6.3.1Satisfaction des exigences fonctionnelles de sécurité...................................................84
6.3.2Satisfaction des exigences d’assurance sécurité............................................................85
7ANNEXE A – ATTAQUES PRISES EN COMPTE PAR LE MOTEUR DE FILTRAGE ASQ...............86
8ANNEXE B – IDENTIFICATION DES OPÉRATIONS EFFECTUÉES SUR LES EXIGENCES DE
SÉCURITÉ DES TI.................................................................................................................................89
8.1Introduction..................................................................................................................................89
8.2Exigences de sécurité pour la TOE...........................................................................................90
8.2.1Exigences de contrôle des flux d’information..................................................................90
8.2.2Exigences de protection contre les attaques Internet.....................................................99
8.2.3Exigences de prévention de l’utilisation impropre.........................................................101
8.2.4Exigences de protection de la TOE..................................................................................103
8.2.5Autres exigences de sécurité de soutien........................................................................104
9ANNEXE C – EXIGENCES DE SÉCURITÉ EXPLICITEMENT ÉNONCÉES....................................107
9.1Introduction................................................................................................................................107
9.2FMT_MOF - Management of functions in TSF........................................................................107
9.2.1FMT_MOF.SSB – Scheduled security behaviour............................................................107
9.3FMT_MTD - Management of TSF data.....................................................................................109
9.3.1FMT_MTD.BRS – Backup and restoration of TSF data..................................................109
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 5 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
C I B L E D E S É C U R I T É
TABLE DES FIGURES
FIGURE 2-2.1. CAS TYPIQUE D’UTILISATION DES COMPOSANTS DE LA TOE............................17
FIGURE 2-2.2. COMPOSANTS ET INTERFACES DE LA TOE............................................................19
FIGURE 2-2.3. PLATE-FORME DE TEST UTILISÉE LORS DE L’ÉVALUATION...............................21
FIGURE 6-6.1. PROTOCOLE ESP EN MODE TUNNEL......................................................................68
FIGURE 6-6.2. CONTENU D'UN DATAGRAMME ESP........................................................................69
FIGURE 6-6.3. DIAGRAMME DE SÉQUENCE – NÉGOCIATION DE SA IPSEC................................70
FIGURE 6-6.4. DIAGRAMME DE CLASSES –FONCTIONS DE CHIFFREMENT ET DE
NÉGOCIATION DES SA.........................................................................................................................
71
FIGURE 6-6.5. DIAGRAMME DE SÉQUENCE – ÉTABLISSEMENT DE SA ISKAMP ET
AUTHENTIFICATION MUTUELLE DES CORRESPONDANTS VPN...................................................72
FIGURE 6-6.6. DIAGRAMME DE SÉQUENCE – PROTOCOLE SRP (SIMPLIFIÉ).............................78
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 6 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
C I B L E D E S É C U R I T É
1 INTRODUCTION
Le but de cette section est de fournir des informations d’identification et de
Le but de cette section est de fournir des informations d’identification et de
référence précises pour le présent document et pour le produit qui fait l’objet de
référence précises pour le présent document et pour le produit qui fait l’objet de
l’évaluation, ainsi que les annonces appropriées de conformité aux Critères
l’évaluation, ainsi que les annonces appropriées de conformité aux Critères
Communs et à d’autres référentiels applicables. Elle apporte également une vue
Communs et à d’autres référentiels applicables. Elle apporte également une vue
d’ensemble des fonctionnalités du firewall-VPN NETASQ.
d’ensemble des fonctionnalités du firewall-VPN NETASQ.
1.1 Identification de la cible de sécurité
Titre : Évaluation de la suite logicielle IPS-Firewall Version 5
Version de la ST : 1.7
Cible d’évaluation : Suite logicielle IPS-Firewall pour boîtiers appliances NETASQ
Version de la TOE : 5.1.4 (S, M, L, XL)
Paquet d’assurance sécurité : EAL2 augmenté de ADV_HLD.2, ADV_LLD.1*
, ADV_IMP.1*
,
ALC_DVS.1, ALC_FLR.3, ALC_TAT.1*
, AVA_MSU.1 et
AVA_VLA.2.
1.2 Annonces de conformité
La version des Critères Communs applicable est la version 2.2 de janvier 2004.
La fonctionnalité de sécurité de la cible d’évaluation est « Conforme à la partie 2 étendue des
Critères Communs ».
Les mesures d’assurance sécurité mises en œuvre sur la cible d’évaluation sont « Conforme à
la partie 3 des Critères Communs ».
Le niveau de résistance minimum des fonctions pour les exigences fonctionnelles de sécurité de
la TOE est ‘SOF-high’. Aucune annonce spécifique supplémentaire de résistance des fonctions
n’est formulée pour les exigences fonctionnelles de sécurité de la TOE.
Aucune annonce de conformité à un quelconque Profil de Protection ou à tout autre paquet
d’exigences de sécurité, que celui sélectionné, n’est formulée.
Le paquet d’assurance sécurité sélectionné est conforme au processus de qualification standard
[QSTD].
1.3 Résumé des fonctionnalités du firewall-VPN NETASQ
Les firewall-VPN de la gamme NETASQ sont des boîtiers appliances fournissant les
fonctionnalités de sécurité autorisant l’interconnexion entre un ou plusieurs réseaux de
confiance (une ou plusieurs DMZ, etc) et un réseau non maîtrisé, sans dégrader le niveau de
sécurité du ou des réseaux de confiance.
Les fonctionnalités principales de la suite logicielle IPS-Firewall, qui équipe ces boîtiers,
consistent en deux grands groupes :
 la fonctionnalité firewall regroupant : filtrage, détection d’attaques, gestion de la bande
passante, gestion de la politique de sécurité, audit, imputabilité, authentification forte des
utilisateurs,
*
Pour les fonctions cryptographiques spécifiées par les composants de la classe FCS uniquement.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 7 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
 la fonctionnalité VPN (Réseau Privé Virtuel : chiffrement et authentification) implémentant le
protocole ESP en mode tunnel du standard IPSec, et sécurisant la transmission des
données confidentielles entre sites distants, partenaires ou commerciaux nomades.
L’ASQ (Active Security Qualification) est une technologie de Prévention d’Intrusion en Temps
Réel, intégrée dans tous les IPS-Firewalls de la gamme NETASQ. Basée sur une analyse multi-
couches, l’ASQ détecte et empêche les attaques les plus élaborées sans diminuer les
performances du boîtier firewall-VPN et réduit considérablement le nombre de faux positifs.
Cette technologie est soutenue par des fonctionnalités d’alarme entièrement configurables.
Pour offrir les fonctionnalités d'authentification forte des utilisateurs, la suite logicielle IPS-
Firewall intègre une base d'utilisateur et offre des services d'authentification auprès de celle-ci.
La suite logicielle IPS-Firewall comprend un package complet de fonctionnalités d’administration
à distance, appelé Administration Suite, constitué des outils Firewall Manager, Firewall Monitor
et Firewall Reporter. Tous ces outils comportent une interface graphique intuitive et conviviale
sous plate-forme Windows, permettant une facilité d’installation et de configuration des boîtiers
appliances firewall-VPN ainsi que des fonctionnalités de monitoring et de reporting simplifiées.
1.4 Documents applicables et de référence
1.4.1 Référentiel des Critères Communs
[CC-01] Common Criteria for Information Technology Security Evaluation, Version 2.2 –
Part 1: Introduction and general model,
CCIMB-2004-01-001, January 2004.
[CC-02] Common Criteria for Information Technology Security Evaluation, Version 2.2 –
Part 2: Security functional requirements
CCIMB-2004-01-002, January 2004.
[CC-03] Common Criteria for Information Technology Security Evaluation, Version 2.2 –
Part 3: Security assurance requirements
CCIMB-2004-01-003, January 2004.
[CEM-02] Common Criteria - Common Methodology for Information Technology Security
Evaluation, Version 2.2 – Evaluation Methodology
CCIMB-2004-01-004, January 2004.
1.4.2 Schéma Français d’Évaluation et de Certification
[MQC] Manuel Qualité du Centre de Certification, Version 1.0
Direction Centrale de la Sécurité des Systèmes d’Information (DCSSI),
CCN-MQ.01, Janvier 2004.
1.4.3 RFC et autres standards
[IP] Postel, J., Internet Protocol, RFC 791, USC/Information Sciences Institute, September
1981.
[ICMP] Postel, J., Internet Control Message Protocol - DARPA Internet Program Protocol
Specification, RFC 792, USC/Information Sciences Institute, September 1981.
[IGMP] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, Internet Group
Management Protocol, Version 3, RFC 3376, October 2002.
[UDP] Postel, J., User Datagram Protocol, STD 6, RFC 768, August 1980.
[TCP] Postel, J., Transmission control protocol, STD 7, RFC 793, September 1981.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 8 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
[IPSec] Kent, S. and R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401,
November 1998.
[ESP] Kent, S. and R. Atkinson, IP Encapsulating Security Protocol (ESP), RFC 2406,
November 1998.
[ISKAMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner, Internet Security
Association and Key Management Protocol (ISAKMP), RFC 2408, November
1998.
[IKE] Harkins, D., and D. Carrel, The Internet Key Exchange (IKE), RFC 2409, November
1998.
[IKE-MODP] T. Kiniven, M. Kojo; More Modular (MODP) Diffie-Hellman groups for Internet
Key Exchange (IKE), RFC 3526, May 2003.
[FTP] Postel, J. and J. Reynolds, File Transfer Protocol (FTP), STD 9, RFC 959, October
1985.
[FTP-security] Allman, M., Ostermann, S., FTP Security Considerations, RFC 2577, May 1999
[FTP-feature] Hethmon, P., Elz, R., Feature negotiation mechanism for the File Transfer
Protocol, RFC 2389, August 1998
[FTP-IPV6] Allman, M., Ostermann, S. and C. Metz, FTP Extensions for IPv6 and NATs,
RFC 2428, September 1998.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L., Leach, P. and T. Berners-
Lee, Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, June 1999.
[WEBDAV] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, HTTP
Extensions for Distributed Authoring - WEBDAV, RFC 2518, February 1999.
[WEBDAV-extensions]
Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. Whitehead, Versioning
Extensions to WebDAV (Web Distributed Authoring and Versioning), RFC 3253,
March 2002.
[DNS-1] Mockapetris, P., Domain names - Concepts and Facilities, STD 13, RFC 1034,
November 1987.
[DNS-2] Mockapetris, P., Domain Names - Implementation and Specification, STD 13,
RFC 1035, November 1987.
[RIP-1] Hedrick, C., Routing Information Protocol, RFC 1058, Rutgers University, June 1988.
[RIP-2] Malkin, G., RIP Version 2, STD 56, RFC 2453, November 1998.
[SRP] Wu, T., The SRP Authentication and Key Exchange System, RFC 2945, September
2000.
[Wu98] T. Wu, “The Secure Remote Password Protocol”, In Proceedings of the 1998 Internet
Society Symposium on Network and Distributed Systems Security, San Diego,
CA, pp. 97-111.
[DH] Rescorla, Diffie-Hellman Key Agreement Method, RFC 2631, June 1999.
[RSA] RSA Laboratories. PKCS #1 v2.1: RSA Encryption Standard. June 2000.
[AES] NIST, FIPS PUB 197, Advanced Encryption Standard (AES), November 2001.
[DES] NIST, FIPS PUB 46-3, Data Encryption Standard (DES), October 1999.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 9 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
[Blowfish] B. Schneier, Fast Software Encryption, Cambridge Security Workshop
Proceedings (December 1993), Springer-Verlag 1994, pp. 191-204.
[CAST] Adams, C., The CAST-128 Encryption Algorithm, RFC 2144, May 1997.
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, HMAC: Keyed-Hashing for Message
Authentication, RFC 2104, February 1997.
[MD5] Rivest, R., The MD5 Message-Digest Algorithm, RFC 1321, April 1992.
[ITSEC] Critères d’évaluation de la sécurité des systèmes informatiques
Commission des Communautés Européennes, version 1.2, juin 1991.
[QSTD] Processus de qualification d’un produit de sécurité - niveau standard
Direction Centrale de la Sécurité des Systèmes d’Information, version 1.0,
juillet 2003.
1.5 Glossaire
Administrateur
Personnel habilité à effectuer certaines opérations d’administration de la
sécurité et responsable de leur exécution correcte.
Auditeur
Administrateur habilité à effectuer des opérations d’audit de la sécurité et de
gestion des traces d’audit, et responsable de leur exécution correcte.
Entité
Agent informatique ou utilisateur humain susceptible d’établir des flux
d’informations avec d’autres entités.
Boîtier appliance firewall-VPN
Équipement NETASQ placé à la frontière entre le réseau non maîtrisé et un ou
plusieurs réseaux de confiance, dédié à la mise en œuvre de la politique de
contrôle des flux d’information.
Association de Sécurité IPSec (SA IPSec)
Connexion unidirectionnelle de niveau transport qui met en œuvre des services
de sécurité sur les flux qu’elle transporte. Du point de vue d’une entité
participant à un tunnel VPN, une SA IPSec peut être entrante ou sortante. Les
SA sortantes servent à encapsuler et à protéger les datagrammes IP sortants,
les SA entrantes servent à décapsuler et à contrôler les datagrammes IP
entrants.
Extrémités du trafic / extrémités du tunnel
Dans le cas d’un tunnel VPN, les extrémités du trafic sont les entités formant les
extrémités d’un flux transitant partiellement par le tunnel, par opposition aux
extrémités du tunnel qui sont les équipements entre lesquels le tunnel est mis
en œuvre. En ESP chiffré en mode tunnel, les adresses IP des extrémités du
trafic sont protégées en confidentialité vis-à-vis d’attaquants capables d’écouter
les flux sur les portions de réseau où le tunnel est mis en œuvre. Seules les
adresses IP des extrémités du tunnel peuvent être lues par ces attaquants.
Correspondant VPN
Entité distante formant l’autre extrémité d’un tunnel VPN.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 10 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
Entité locale / entité distante
Dans le cas d’un tunnel VPN, les entités locales sont les extrémités du trafic
dont les flux parviennent au boîtier appliance firewall-VPN non encapsulés par
ESP, et qui doivent l’être avant leur retransmission à l’autre extrémité du trafic
via le correspondant VPN. Les entités distantes sont celles dont les flux
parviennent au boîtier appliance firewall-VPN via le correspondant VPN et
encapsulés par ESP.
Console locale
Terminal physiquement connecté sur un boîtier appliance firewall-VPN, servant
à procéder à des opérations d’installation ou de maintenance du logiciel de ce
boîtier.
Opérations d’administration de la sécurité
Opérations effectuées sur les boîtiers appliances firewall-VPN, confiées à la
responsabilité d’un administrateur au titre de la politique de sécurité interne de
l’organisation exploitant les réseaux de confiance. Ces opérations peuvent être
dictées par la politique de sécurité interne (ex : revues d’audit) ou par la
nécessité de maintenir la TOE dans des conditions d’exploitation nominales
(ex : modification de la configuration des fonctions de contrôle des flux
d’information, purge des journaux d’audit, arrêt/redémarrage du logiciel IPS-
Firewall). Elles sont caractérisées par le fait d’avoir pour effet éventuel de
modifier le comportement des fonctions de sécurité de la TOE.
Politique de filtrage
Ensemble de règles techniques décrivant quelles entités ont le droit d’établir des
flux d’information avec quelles autres entités.
Politique de chiffrement
Ensemble de règles techniques décrivant les traitements de chiffrement à
appliquer à certains flux d’information dans le but de les protéger en
confidentialité et en intégrité.
Politique de contrôle des flux d’information
Ensemble de règles techniques constitué de la politique de filtrage et de la
politique de chifffrement.
Pseudo-connexion
1º) Ensemble de datagrammes UDP associés à un même échange applicatif.
2º) Ensemble de messages ICMP associés à un échange de type requête /
réponse dans le cadre de l’utilisation de ce protocole (ex : ‘echo request’ / ‘echo
reply’).
Réseau de confiance
Un réseau est dit de confiance si, du fait qu’il est sous le contrôle de l’exploitant
de la TOE, la politique de sécurité interne n’implique pas qu’il faille se protéger
des flux qui en proviennent, mais au contraire implique qu’il faille les protéger
des flux qui y parviennent.
Réseau non maîtrisé
Un réseau est dit non maîtrisé s’il n’est pas sous le contrôle de l’exploitant de la
TOE, ce qui implique qu’il faille se protéger des flux établis avec les
équipements de ce réseau (par exemple Internet).
SRP Secure Remote Password. Protocole d’authentification mutuelle basé un mot de passe
réutilisable, sans divulgation de celui-ci..
Station d’administration à distance
Station de travail muni d’un logiciel NETASQ, connecté à un réseau de
confiance ou non maîtrisé, dédiée aux opérations d’administration de la sécurité
d’un ou plusieurs boîtiers appliances firewall-VPN à travers des sessions
sécurisées d’administration de la sécurité.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 11 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
45
50
C I B L E D E S É C U R I T É
Super-administrateur
Administrateur disposant de droits complets sur la configuration des boîtiers
appliances firewall-VPN, seul habilité à s’y connecter à l’aide de la console
locale, à définir les profils des autres administrateurs, et ne devant accomplir
cette tâche qu’en dehors des phases d’exploitation (i.e. installation ou
maintenance).
Utilisateur
Personne utilisant des ressources informatiques des réseaux de confiance
protégées par la TOE à partir d’autres réseaux de confiance ou du réseau non
maîtrisé.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 12 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
C I B L E D E S É C U R I T É
2 DESCRIPTION DE LA CIBLE D’ÉVALUATION
Le but de cette section est de présenter les notions qui vont être utilisées par la
Le but de cette section est de présenter les notions qui vont être utilisées par la
suite dans l’énoncé de la problématique de sécurité à laquelle répond la TOE, des
suite dans l’énoncé de la problématique de sécurité à laquelle répond la TOE, des
objectifs de sécurité et des exigences de sécurité de la TOE. Elle sert aussi à
objectifs de sécurité et des exigences de sécurité de la TOE. Elle sert aussi à
préciser la portée et les limites de l’évaluation.
préciser la portée et les limites de l’évaluation.
2.1 Caractéristiques de sécurité TI de la TOE
2.1.1 Généralités
La sécurisation de l’interconnexion entre des réseaux de confiance appartenant à une
organisation et un réseau non maîtrisé nécessite la définition, par le responsable SSI de
l’organisation, d’une politique de sécurité interne, récapitulant ou référençant les « lois,
règlements et pratiques qui régissent la façon de gérer, protéger et diffuser les biens, en
particulier les informations sensibles », au sein de l’organisation [ITSEC 2.10].
La politique de sécurité interne peut faire peser des exigences d’ordre technique sur le réseau et
des contraintes sur les mesures physiques, relatives au personnel ou organisationnelles de son
environnement d’exploitation. La suite logicielle NETASQ IPS-Firewall vise à répondre, dans
le contexte de l’évaluation, aux exigences d’ordre technique de contrôle des flux d’information
par des fonctionnalités de filtrage élaboré et des fonctionnalités chiffrement de type VPN (virtual
private network – réseau privé virtuel).
2.1.2 Le contrôle des flux d’information
Cet ensemble d’exigences est la raison d’être d’un produit de type firewall-VPN. La politique de
sécurité interne doit permettre de déduire :
 quelles entités (utilisateurs ou agents informatiques) ont le droit d’établir des flux
d’information avec quelles autres entités, c’est ce qu’on appelle la politique de filtrage,
 parmi les flux d’information autorisés, lesquels nécessitent des protections en confidentialité
ou en intégrité, et la nature de ces protections (protocoles et algorithmes de chiffrement),
c’est ce qu’on appelle la politique de chiffrement.
Suivant les cas, les règles de cette politique de chiffrement et de filtrage, également appelée
politique de contrôle des flux d’information, peuvent s’exprimer selon des critères plus ou
moins sophistiqués : adresses IP source et destination, nº de protocole IP utilisé, port TCP/UDP
source/destination, heure de la journée et jour de la semaine, identité de l’utilisateur,
authentification préalable, etc.
La suite logicielle NETASQ IPS-Firewall fournit les fonctionnalités de filtrage suivantes :
 Filtrage des flux entre les équipements (stateful inspection), sur la base :
 des caractéristiques au niveau IP et transport : n° de protocole IP, adresses IP source et
destination, ports TCP/UDP source et destination,
 de l’identité déclarée par les utilisateurs, suite à une étape
d’identification/authentification ;
 Limitation du débit de certains flux ;
 Imputabilité des flux aux entités les ayant suscités ;
 Variabilité du comportement des fonctions de filtrage en fonction de la date et de l’heure.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 13 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
Les fonctionnalités de chiffrement sont celles offertes en standard par le protocole ESP en
mode tunnel d’IPSec [ESP, IPSec], associé à ISAKMP [ISAKMP] et à IKE [IKE] pour la
négociation des paramètres de sécurité et des clés de session :
 Confidentialité du contenu des flux ;
 Anonymat des équipements d’extrémité du trafic ;
 Intégrité du contenu des flux : intégrité des paquets, protection contre le rejeu,
authentification de l’émetteur du paquet chiffré ;
 Authentification mutuelle des extrémités du tunnel (i.e. la portion du flux sur laquelle le
chiffrement est appliqué).
L’interopérabilité du module VPN de la suite logicielle NETASQ IPS-Firewall permet de
l’interconnecter à des systèmes de chiffrement IPSec hétérogènes.
Ces deux grands ensembles fonctionnels sont complétés par des fonctionnalités de remontée
d’alarmes que l’administrateur peut définir à partir de l’ensemble des événements de sécurité
que le firewall est susceptible de détecter (événements de filtrage, de chiffrement, événements
remontés par le moteur ASQ (cf. § 2.1.3infra), événements système bas niveau
(arrêt/démarrage du firewall-VPN, erreurs hardware, etc.)).
2.1.3 La protection contre les attaques Internet
Le contrôle du trafic entre plusieurs réseaux de confiance et le réseau non maîtrisé permet de
rejeter des tentatives évidentes d’établissement de flux illicites vis-à-vis de la politique de
contrôle des flux d’information.
Néanmoins, à l’intérieur des limites d’une politique de contrôle des flux d’information adaptée au
réseau et correctement implémentée au niveau du firewall-VPN, subsiste la possibilité pour des
attaquants possédant un accès au réseau non maîtrisé :
 de contourner la politique de contrôle des flux d’information mise en œuvre par le firewall-
VPN,
 et/ou d’« attaquer » les équipements des réseaux de confiance en se basant sur des détails
et des erreurs de conception et d’implémentation des protocoles réseaux (IP, TCP, UDP,
protocoles applicatifs).
Les effets de ce genre d’attaques peuvent être :
 une intrusion, c’est-à-dire un accès non autorisé à un service, ou aux fonctions du système
d’exploitation d’un équipement ;
 le blocage ou le redémarrage d’un équipement, provoquant un déni de service ;
 la saturation des équipements réseau provoquant un déni de service ;
 la divulgation de la topologie et/ou des détails techniques des équipements du réseau de
confiance dans le but d’obtenir des accès non autorisés supplémentaires à partir d’une
première intrusion réussie.
Par ailleurs, un attaquant capable d’écouter les flux entre un utilisateur légitime du réseau non
maîtrisé et un service du réseau de confiance, puis de contrefaire des paquets IP, peut tenter
d’usurper l’identité de cet utilisateur :
 soit en rejouant ses données d’authentification si celles-ci sont constantes (ex : mot de
passe réutilisable),
 soit en tentant de les deviner (au hasard ou par prédiction sur la base d’analyses
cryptographiques) si celles-ci comportent des éléments diversifiants.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 14 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
Pour contrer ce risque, la suite logicielle NETASQ IPS-Firewall propose des fonctions de
prévention des intrusions, basées sur la technologie ASQ. Cette technologie inclut un
moteur d’analyse dynamique aux niveaux IP, transport et applicatif avec optimisation des règles
permettant l’application de la politique de contrôle des flux d’information de façon sûre et rapide.
Elle permet :
 La détection d’attaques sans contexte de connexion, par exemple :
 l’usurpation d’adresse IP (IP spoofing) par la corrélation de l’adresse IP source et de
l’interface de réception des paquets,
 les paquets contrefaits comme ceux de type ‘xmas tree’ (toutes les options TCP sont
mises) ou ‘land’ (l’adresse source et l’adresse destination sont identiques) qui visent à
provoquer des défaillances sur les équipements cibles,
 les recouvrements de fragments dans le but de provoquer des défaillances sur les
équipements cibles ou de contourner la politique de contrôle des flux d’information,
 les tentatives de débordement mémoire au niveau applicatif ;
 La détection des attaques avec contexte de connexion comme par exemple :
 l’utilisation de numéros de séquence TCP incorrects ou hors fenêtre,
 les attaques exhaustives (brute force) sur les mots de passe FTP ;
 La détection des attaques globales nécessitant de recouper les caractéristiques de
nombreux flux d’information distincts comme par exemple :
 la saturation des ressources des serveurs, par l’envoi d’un nombre abusif de demandes
d’ouvertures de connexion TCP non acquitées (SYN flooding),
 les tentatives de sondage de la topologie interne des réseaux de confiance avec les
utilitaires nmap ou queso.
L’annexe A, § 7 contient une liste exhaustive des attaques actuellement prises en compte par le
moteur de filtrage ASQ.
Les tentatives d’usurpation de l’identité des utilisateurs autorisés sont contrées par la fourniture
par le boîtier appliance firewall-VPN de mécanismes d’authentification forte des utilisateurs
comme le défi / réponse basé sur le protocole SRP.
2.1.4 Les risques d’utilisation impropre
La déclinaison d’une politique de contrôle des flux d’information au niveau de la configuration
d’un firewall-VPN, ainsi que l’exploitation de ce type de produit (audits, réactions vis-à-vis des
alarmes, etc.) est en général une tâche complexe, nécessitant des compétences spécifiques et
présentant, en conséquence, des risques d’erreurs.
Ces risques rendent souhaitable une séparation des rôles administratifs afin de garantir que les
seules personnes à même d’accomplir une activité d’exploitation donnée sont celles qui sont
spécifiquement habilitées et formées pour le faire. À cet effet, la suite logicielle NETASQ IPS-
Firewall fournit des fonctions de contrôle d’accès aux opérations d’administration de la
sécurité basées sur des droits permettant de constituer des profils administrateurs. La définition
des profils est du ressort d’un administrateur spécial, le « super-administrateur », qui intervient
exclusivement lors des phases d’installation et de maintenance et est le seul habilité à se
connecter à la console locale.
Des fonctions de sauvegarde et de restitution des configurations réduisent le risque
d’erreur en permettant de conserver des configurations types répondant à problématiques bien
définies, et de revenir en arrière en cas d’erreur de manipulation.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 15 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
La qualité de la documentation d’exploitation et la facilité d’utilisation des interfaces ont
également un impact sur ce type de risque.
2.1.5 La protection de la TOE elle-même
Si on suppose que les fonctions de sécurité de la TOE sont efficaces pour implémenter la
politique de sécurité réseau et contrer les attaques, et correctement configurées, la seule
solution pour réussir une attaque c’est de modifier le comportement de la TOE :
 Soit en désactivant les fonctions de sécurité ou en modifiant leur configuration, par le biais
d’une attaque locale ou distante exploitant d’éventuelles vulnérabilités permettant de
contourner les fonctions de contrôle d’accès aux opérations d’administration, sans
nécessiter de droits particuliers ;
 Soit obtenant un accès administrateur légitime (par collusion avec un administrateur, en
devinant son mot de passe, etc.).
Pour contrer ce risque, des mesures doivent être prises au niveau de la sécurité physique et
logique des boîtiers appliances firewall-VPN et aussi des stations d’administration à distance
(local à accès contrôlé, interdiction d’utiliser une console locale dans des conditions
d’exploitation, etc.). Les fonctions de contrôle d’accès aux opérations d’administration évoqués
au § 2.1.4supra sont soutenues par des mécanismes d’authentification forte des
administrateurs basés sur l’algorithme SRP. Par ailleurs l’administration à distance pouvant
être effectuée à partir du réseau non maîtrisé, la suite logicielle NETASQ IPS-Firewall fournit
des fonctions de protection des sessions d’administration en confidentialité et en
intégrité basées sur des opérations cryptographiques de chiffrement (AES 128 bits). Ces
fonctions forment un ensemble distinct des fonctions de chiffrement IPSec et sont donc fournies
dans tous les cas.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 16 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
C I B L E D E S É C U R I T É
2.2 Limites physiques de la TOE
2.2.1 Équipements constituant la TOE
Une plate-forme sur laquelle la TOE s’exécute est constituée de deux types d’équipements :
 Des boîtiers appliances firewall-VPN, sur lesquelles s’exécute le logiciel IPS-Firewall
NETASQ. Ces boîtiers mettent en œuvre les fonctions de filtrage et de chiffrement de la
TOE, entre les différents sous-réseaux reliés à leurs interfaces ;
 Des stations d’administration à distance, reliées au boîtier de façon sécurisée et sur
lesquelles tourne le package NETASQ Administration suite (IHM) dédié à la gestion de la
politique de filtrage et de chiffrement, le monitoring en temps réel, l’acquittement des
alarmes et l’audit de la TOE par l’administrateur, et la gestion des comptes administrateurs.
Figure 2-2.1. Cas typique d’utilisation des composants de la TOE.
Dans l’exemple d’architecture réseau présenté ci-dessus, les boîtiers appliances firewall-VPN
sont déployés à la frontière entre chaque réseau de confiance et le réseau non maîtrisé. Il
servent à protéger les stations et les serveurs présents sur les réseaux de confiance, en
contrôlant tous les flux d’information qui transitent par cette frontière.
Ils mettent également en œuvre des tunnels VPN sur la portion du réseau non maîtrisé où ces
flux sont véhiculés, aussi bien entre deux boîtiers qu’entre un boîtier et un poste nomade équipé
d’un client VPN connecté sur le réseau non maîtrisé.
Les postes nomades ne font pas partie de la TOE, qu’ils soient équipés du client VPN fourni par
NETASQ ou d’un autre logiciel.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 17 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
C I B L E D E S É C U R I T É
Les stations d’administration à distance peuvent être connectées au réseau non maîtrisé ou à
un réseau de confiance.
2.2.2 Caractéristiques minimum des plates-formes d’exploitation
Les boîtiers appliances firewall-VPN sont entièrement packagés par NETASQ. Ils sont
développés autour du noyau FreeBSD 4.7, avec patches à jour, adapté et épuré par NETASQ.
Il est à noter que seule la partie logiciel et non le matériel est soumise à l'évaluation.
Pour les stations d’administration à distance :
 PC Pentium III ;
 128 Mo de RAM (256 Mo conseillés) ;
 100 Mo de disque dur ;
 Carte réseau Ethernet 10 ou 100 Mbps ;
 Windows Internet Explorer 5 ou plus ;
 Windows 2000 (SP3) ou XP (SP1).
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 18 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
C I B L E D E S É C U R I T É
2.3 Limites logiques de la TOE
2.3.1 Composants logiciels
Le logiciel à évaluer est constitué des composants suivants :
 Logiciel IPS-Firewall pour boîtier appliance firewall-VPN, aussi appelé NS-BSD, incluant le
noyau FreeBSD 4.7 avec patches à jour, adapté et épuré par NETASQ,
 NETASQ Firewall Manager : Interface graphique d’administration et de configuration des
firewalls NETASQ,
 NETASQ Firewall Monitor : Interface graphique de supervision et de monitoring d’un ou de
plusieurs firewalls,
 NETASQ Firewall Reporter : Interface graphique d’analyse des logs et de reporting.
2.3.2 Architecture et interfaces de la TOE
Une TOE en exploitation est un produit réparti sur des boîtiers appliances firewall-VPN, et une
ou plusieurs stations d’administration à distance. La figure ci-dessous schématise les interfaces
existant entre ces composants ainsi qu’avec les autres entités TI hors TOE et les utilisateurs.
Figure 2-2.2. Composants et interfaces de la TOE.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 19 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
C I B L E D E S É C U R I T É
2.3.3 Configurations et modes d’utilisation soumis à l’évaluation
Le mode d’utilisation soumis à l’évaluation présente les caractéristiques suivantes :
 L’évaluation porte sur la suite logicielle IPS-Firewall qui équipe toutes les versions des
boîtiers firewall-VPN, du F50 au F5000 ; Celle-ci se décline en 4 compilations distinctes
(build S, M, L, XL) selon la position dans la gamme.
 Les boîtiers appliances firewall-VPN doivent être stockés dans un local à accès sécurisé.
Ces mesures, ainsi que les procédures organisationnelles de l’environnement d’exploitation,
doivent garantir que les seuls accès physiques aux boîtiers appliances firewall-VPN se font
sous la surveillance du super-administrateur ;
 La console locale n’est pas utilisée en exploitation. Seul le super-administrateur peut s’y
connecter, et, par hypothèse, ce genre d’intervention ne se fait que lorsqu’une sortie du
cadre de l’exploitation – pour procéder à une maintenance ou à une ré-installation – est
décidée ;
 Les stations sur lesquelles s’exécutent la suite logicielle d’administration à distance sont
sécurisées, dédiées à cette utilisation, et à jour de tous les correctifs concernant leur
système d’exploitation et les logiciels applicatifs qui les équipent ;
 Tous les administrateurs sont soumis à une étape identification / authentification utilisant le
protocole SRP offert par la TOE ;
 Les méthodes d’authentification des utilisateurs sont également celles basées sur le
protocole SRP offert par la TOE (Note: l'accès HTTPS est hors évaluation car n'apporte pas
de niveau de sécurité supplémentaire vis-à-vis de SRP) ;
 La TOE est configurée de sorte que les utilisateurs ne puissent pas changer leurs mots de
passe ;
 Le mode de distribution des certificats et des CRL est manuelle (importation).
 Le logiciel VPN client ne fait pas partie de l’évaluation ; du reste les utilisateurs peuvent
utiliser le client IPSec de leur choix. Cependant, ces postes clients doivent être sécurisés
avec un niveau de rigueur équivalent à celui des stations d’administration à distance ;
 Le mode d’utilisation soumis à l’évaluation exclut le fait que la TOE s’appuie sur d’autres
services tels que PKI, serveur DNS, DHCP, proxies. Les modules que NETASQ fournit en
option pour la prise en charge de ces services sont désactivés par défaut et doivent le
rester1
. Il s’agit précisément :
 des modules permettant la prise en charge des serveurs externes (ex : Kerberos,
RADIUS, Syslog...),
 de l'infrastructure à clés publiques (PKI) interne,
 des proxies HTTP et SMTP,
 du cache DNS,
 des serveurs SSH, DHCP, MPD et SNMPD,
 du client DHCP et du démon NTP ;
 Les utilisateurs sont gérés par une base LDAP interne au logiciel IPS-Firewall et qui fait
partie de la TOE. Le mode d’utilisation soumis à l’évaluation exclut le fait que des clients
LDAP externes au boîtier appliance firewall-VPN puissent se connecter à cette base ;
1
Les outils d’administration et de monitoring fournissent le moyen de vérifier, à tout moment lors de l’exploitation, que c’est bien le cas.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 20 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
 La technologie ASQ met en œuvre des analyses contextuelles au niveau applicatif, dans le
but de vérifier la conformité aux RFC et de contrer les attaques au niveau applicatif. Les
fonctions d’analyse applicative qui font l’objet de l’évaluation sont celles associées aux
protocoles FTP, HTTP (incluant les extensions WEBDAV), H.323, RIP et DNS ;
 L’utilisation de la translation d’adresses (network address translation ou NAT) est possible
mais n’est pas considérée comme une fonction de sécurité.
2.4 Plate-forme de test utilisée lors de l’évaluation
Figure 2-2.3. Plate-forme de test utilisée lors de l’évaluation.
Le boîtier appliance firewall-VPN est un F200.
Le système d’exploitation de la station d’administration à distance est Windows 2000 SP3.
Le logiciel du poste client nomade et des serveurs est constitué par des produits grand public
représentatifs (ex : navigateurs, clients de messagerie, serveurs Web) et des applications
développées spécifiquement aux fins des tests de conformité ou de pénétration (scripts,
programmes d’attaque, etc.). Le poste client nomade est également équipé du logiciel client
VPN NETASQ (non soumis à l’évaluation).
Des ordinateurs portables équipés de logiciels « sondes » servent à écouter les flux pour
estimer la conformité du comportement du boîtier appliance firewall-VPN au niveau des
interfaces réseau, ainsi qu’à mener des tests de pénétration en contrefaisant des paquets. Ils
sont susceptibles d’être connectés en différents points du réseau.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 21 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
C I B L E D E S É C U R I T É
3 ENVIRONNEMENT DE SÉCURITÉ DE LA CIBLE D’ÉVALUATION
Le but de cette section est de décrire le problème de sécurité auquel la TOE doit
Le but de cette section est de décrire le problème de sécurité auquel la TOE doit
répondre sous la forme d’un jeu de menaces que la TOE doit contrer et des règles
répondre sous la forme d’un jeu de menaces que la TOE doit contrer et des règles
de la politique de sécurité que la TOE doit satisfaire. Cette spécification du
de la politique de sécurité que la TOE doit satisfaire. Cette spécification du
cahier des charges sécuritaire du produit est faite moyennant des hypothèses
cahier des charges sécuritaire du produit est faite moyennant des hypothèses
portant sur les caractéristiques de sécurité de l’environnement dans lequel il est
portant sur les caractéristiques de sécurité de l’environnement dans lequel il est
prévu d’utiliser la TOE ainsi que sur son mode d’utilisation attendu.
prévu d’utiliser la TOE ainsi que sur son mode d’utilisation attendu.
3.1 Identification des biens sensibles
3.1.1 Biens protégés par la TOE
Le firewall-VPN NETASQ contribue à protéger les biens sensibles suivants, sous réserve d’une
définition correcte et réalisable de la politique de contrôle des flux d’information à mettre en
œuvre au niveau du système d’information dans sa globalité (cf. HO.BONNE_PCFI) :
 Les services applicatifs proposés par les serveurs des réseaux de confiance (en
confidentialité, intégrité et disponibilité) ;
 Les logiciels s’exécutant sur les équipements des réseaux de confiance (serveurs,
navigateurs, etc.), et la configuration de ces logiciels (intégrité et confidentialité) ;
 Le contenu des flux d’information transitant sur le réseau non maîtrisé, pour lesquels la
mise en œuvre de VPN est envisageable (confidentialité et intégrité) ;
 Les informations de topologie du réseau (confidentialité), contre des tentatives de sondage
basées sur une utilisation des protocoles Internet contraires aux bonnes pratiques.
3.1.2 Biens appartenant à la TOE
Dans le but de protéger ces biens sensibles externes, les différents composants de la suite
logicielle NETASQ IPS-Firewall protègent également leurs propres paramètres de sécurité en
confidentialité et en intégrité lors des échanges entre eux (sessions d’administration).
Par ailleurs, les biens sensibles de la TOE sont composés des données liées aux fonctions de
sécurité de la TOE (TSF-Datas).
Les TSF-datas sont composées :
 des paramètres de configuration de la TOE,
 des politiques de contrôle de flux implémentée par la TOE,
 des contextes d’utilisation,
 des enregistrements d’événements de la TOE,
 des données d’authentification des administrateurs et des utilisateurs.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 22 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
C I B L E D E S É C U R I T É
3.2 Menaces et règles de la politique de sécurité
L’énoncé des menaces et des règles de la politique de sécurité reprend le plan suivi pour la
description des caractéristiques de sécurité TI de la TOE.
3.2.1 Le contrôle des flux d’information
P.FILTRAGE
La TOE doit appliquer la politique de filtrage définie par l’administrateur.
Cette politique s’exprime en termes de l’autorisation ou non d’établir des flux
en fonction :
de ses caractéristiques au niveau IP (adresse source et destination, type
de protocole IP) et transport (port source et destination TCP ou UDP),
de l’identité de l’utilisateur qui le suscite et de la réussite d’une étape
d’authentification,
de la date et de l’heure courante.
P.VPN
La TOE doit appliquer la politique de chiffrement définie par l’administrateur.
Cette politique s’exprime en termes :
de l’application des fonctions de chiffrement sur les flux en fonction de
leurs caractéristiques au niveau IP (adresse source et destination, type
de protocole IP),
des conditions de l’établissement des sessions IPSec (clé pré-partagée
ou certificat, identité attendue du correspondant VPN),
des paramètres ESP utilisés (algorithmes d’authentification et de
chiffrement des trames et longueur des clés associées).
P.AUDIT_ALARME
La TOE doit :
enregistrer les événements de filtrage (incluant flux et rejets) et de
chiffrement jugés sensibles par l’administrateur et fournir les moyens de
les imputer ultérieurement aux entités qui les ont suscités, à travers un
audit ;
remonter des alarmes de sécurité pour les événements de filtrage, de
chiffrement, liés à l’analyse contextuelle (cf. P.ANALYSE) ou à l’activité
du logiciel des boîtiers appliances firewall-VPN, spécifiés comme tels par
l’administrateur.
3.2.2 La protection contre les attaques Internet
P.ANALYSE
La TOE doit analyser les flux d’informations qui transitent par les boîtiers
appliances firewall-VPN, détecter et éventuellement détruire sans les
transmettre les types de flux suivants, potentiellement dangereux pour
l’entité réceptrice :
ceux pouvant divulguer la topologie du réseau (ex : option route
recording),
ceux valides au sens des protocoles Internet mais ne correspondant pas
à certaines règles de bonnes pratiques (ex : ICMP redirect),
ceux pouvant provoquer des fautes logicielles sur les équipements
destinataires,
ceux pouvant saturer les capacités de communication et de traitement
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 23 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
45
C I B L E D E S É C U R I T É
des équipements destinataires.
M.IP_USURP
Une entité non-autorisée sur le réseau non maîtrisé contourne la politique de
contrôle des flux d’informations en contrefaisant l’adresse IP source des
paquets qu’il émet afin d’usurper l’identité d’une entité réseau autorisé.
M.UTIL_USURP
Une entité non-autorisée sur le réseau non maîtrisé parvient à accéder aux
services réservés à un utilisateur soumis à une authentification obligatoire
autorisé en usurpant son identité :
soit en rejouant une séquence d’authentification légitime basée sur des
données réutilisables qu’elle a interceptée,
soit en devinant les données d’authentification de l’utilisateur suite à des
tentatives aléatoires répétées, ou par le biais d’analyses de séquences
d’authentification interceptées.
3.2.3 Les risques d’utilisation impropre
M.MAUVAIS_USAGE
Les fonctions de sécurité de la TOE ne se comportent pas en accord avec la
politique de sécurité interne, du fait qu’un administrateur n’exerce pas
correctement les responsabilités liées à son rôle, soit qu’il configure mal la
TOE, soit qu’il l’exploite d’une manière non conforme à ses responsabilités
ou au mode d’utilisation prévu.
P.SAUVEGARDE_RESTAURATION
La TOE doit fournir des moyens de sauvegarder sa configuration, et de
restaurer celle-ci ultérieurement, dans le but de faciliter la tâche de
l’administrateur.
3.2.4 La protection de la TOE elle-même
M.ADMIN_ILLICITE
Un attaquant ou une entité non-autorisée parvient à effectuer des opérations
d’administration illicites.
M.ADMIN_USURP
Une entité non-autorisée sur le réseau non maîtrisé parvient à établir une
session d’administration sur un boîtier appliance firewall-VPN en usurpant
l’identité d’un administrateur suite à des tentatives aléatoires répétées, ou
par le biais d’analyses de séquences d’authentification interceptées.
M.SESSION_ADMIN_ILLICITE
Une entité non-autorisée lit, modifie ou supprime le contenu d’une session
d’administration établie entre un boîtier appliance firewall-VPN et une station
d’administration à distance pour le compte d’un administrateur.
Note : M.ADMIN_USURP et M.SESSION_ADMIN_ILLICITE sont des prérequis (non-exhaustifs)
permettant de réaliser la menace M.ADMIN_ILLICITE.
M.PERTE_AUDIT
Une entité non-autorisée empêche l’enregistrement d’événements de
sécurité en épuisant la capacité de stockage par la TOE de ces événements,
dans le but de masquer les actions illicites d'un attaquant.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 24 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
3.3 Hypothèses
3.3.1 Hypothèses sur les mesures de sécurité physiques
HP.PROTECT_BOITIERS
Les boîtiers appliances firewall-VPN sont installés et stockés conformément
à l’état de l’art concernant les dispositifs de sécurité sensibles : local à accès
protégé, câbles blindés en paire torsadée, étiquetage des câbles, etc.
3.3.2 Hypothèses sur les mesures de sécurité organisationnelles
HO.SUPER_ADMIN
Un rôle administrateur particulier, le super-administrateur, présente les
caractéristiques suivantes :
Il est le seul à être habilité à se connecter via la console locale sur les
boîtiers appliances firewall-VPN, et ce uniquement lors de l’installation
de la TOE ou pour des opérations de maintenance, en dehors de
l’exploitation ;
Il est chargé de la définition des profils des autres administrateurs ;
Tous les accès dans les locaux où sont stockés les boîtiers appliances
firewall-VPN se font sous sa surveillance, que l’accès soit motivé par des
interventions sur les boîtiers ou sur d’autres équipements. Toutes les
interventions sur les boîtiers appliances firewall-VPN se font sous sa
responsabilité.
HO.MOT_PASSE
Les mots de passe des utilisateurs et des administrateurs doivent être
choisis de façon à retarder toutes les attaques visant à les casser, via une
politique de création et/ou de contrôle de ceux-ci (par ex : mélange
alphanumérique, longueur minimum, ajout de caractères spéciaux, pas de
mots des dictionnaires usuels, etc.).
Il est de la responsabilité des administrateurs de sensibiliser tous les
utilisateurs à ces bonnes pratiques.
HO.BONNE_PCFI
La politique de contrôle des flux d’informations à mettre en œuvre est
définie, pour tous les équipements des réseaux de confiance à protéger, de
manière :
complète : les cas d’utilisation standards des équipements ont tous été
envisagés lors de la définition des règles et leurs limites autorisées ont
été définies,
stricte : seuls les cas d’utilisation nécessaires des équipements sont
autorisés,
correcte : les règles ne présentent pas de contradiction,
non-ambiguë : l’énoncé des règles fournit tous les éléments pertinents
pour un paramétrage direct de la TOE par un administrateur compétent.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 25 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
3.3.3 Hypothèses relatives aux agents humains
HH.PERSONNEL
Les administrateurs sont des personnes non hostiles et compétentes,
disposant des moyens nécessaires à l’accomplissement de leurs tâches. Ils
sont formés pour exécuter les opérations dont ils ont la responsabilité.
Notamment, leur compétence et leur organisation implique que :
Différents administrateurs avec les mêmes droits ne mènent des actions
d’administration qui se contredisent (ex : modifications incohérentes de
politique de contrôle des flux d’information) ;
L’exploitation des journaux et le traitement des alarmes sont effectués
dans les délais appropriés.
3.3.4 Hypothèses sur l’environnement de sécurité TI
HTI.COUPURE
Les boîtiers appliances firewall-VPN sont installés conformément à la
politique d’interconnexion des réseaux en vigueur et sont les seuls points de
passage entre les différents réseaux sur lesquels il faut appliquer la politique
de contrôle des flux d’information.
HTI.USAGE_STRICT
À part l’application des fonctions de sécurité, les boîtiers appliances firewall-
VPN ne fournissent pas de service réseau autre que le routage et la
translation d’adresse (ex : pas de DHCP, DNS, PKI, proxies applicatifs, etc.).
Les boîtiers appliances firewall-VPN ne sont pas configurés pour
retransmettre les flux IPX, Netbios, AppleTalk, PPPoE ou IPv6.
HTI.AUTONOME
La TOE ne dépend pas de services externes « en ligne » (DNS, DHCP,
RADIUS, etc.) pour l’application de la politique de contrôle des flux
d’information.
HTI.PROTECT_STATIONS
Les stations d’administration à distance sont sécurisées et maintenues à jour
de toutes les vulnérabilités connues concernant les systèmes d’exploitation
et les applications hébergées. Elles sont installés dans des locaux à accès
protégé et sont exclusivement dédiées à l’administration de la TOE et au
stockage des sauvegardes.
HTI.PROTECT_CORRESP_VPN
Les équipements réseau avec lesquels la TOE établit des tunnels VPN sont
sont soumis à des contraintes de contrôle d’accès physique, de protection et
de maîtrise de leur configuration équivalentes à celles des boîtiers
appliances firewall-VPN de la TOE.
HTI.PROTECT_CLIENTS_VPN
Les postes sur lesquels s’exécutent les clients VPN des utilisateurs autorisés
sont soumis à des contraintes de contrôle d’accès physique, de protection et
de maîtrise de leur configuration équivalentes à celles des postes clients des
réseau de confiance. Ils sont sécurisés et maintenus à jour de toutes les
vulnérabilités connues concernant les systèmes d’exploitation et les
applications hébergées.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 26 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
45
C I B L E D E S É C U R I T É
4 OBJECTIFS DE SÉCURITÉ
Le but de cette section est de fournir une présentation concise de la réponse
Le but de cette section est de fournir une présentation concise de la réponse
prévue au problème de sécurité, sous la forme d’objectifs de sécurité. Les
prévue au problème de sécurité, sous la forme d’objectifs de sécurité. Les
objectifs de sécurité sont normalement classés en objectifs de sécurité pour la
objectifs de sécurité sont normalement classés en objectifs de sécurité pour la
TOE et en objectifs de sécurité pour l’environnement. L’argumentaire des
TOE et en objectifs de sécurité pour l’environnement. L’argumentaire des
objectifs de sécurité doit montrer que les objectifs de sécurité pour la TOE et
objectifs de sécurité doit montrer que les objectifs de sécurité pour la TOE et
pour l’environnement sont reliés aux menaces identifiées devant être contrées
pour l’environnement sont reliés aux menaces identifiées devant être contrées
ou aux règles de la politique de sécurité et hypothèses devant être satisfaites par
ou aux règles de la politique de sécurité et hypothèses devant être satisfaites par
chacun d’entre eux.
chacun d’entre eux.
4.1 Généralités
La présentation des objectifs de sécurité pour la TOE reprend le plan suivi pour la description
des caractéristiques de sécurité TI de la TOE et l’énoncé des menaces et des règles de la
politique de sécurité.
L’argumentaire de chaque objectif de sécurité de la TOE est fourni immédiatement après
l’énoncé de l’objectif, plutôt que dans une section à part. Un tableau récapitulatif est fourni à la
fin de cette section.
Concernant les objectifs de sécurité O.PCAOA, O.PCAOA_I&A_ADMIN et
O.RESIST_AUTH_ADMIN, il convient de noter que la politique de contrôle de l’accès aux
opérations d’administration de la sécurité concourt en fait à la fois :
 à la prévention de l’utilisation impropre, en permettant d’implémenter une séparation des
tâches d’administration adaptée à la responsabilité et à la compétence de chaque
administrateur, dictées par les contraintes de l’organisation exploitant les réseaux de
confiance,
 et à la protection de la TOE elle-même, puisqu’elle prévient les opérations d’administration
illicites.
Ainsi, ces trois objectifs couvrent les problématiques abordées au § 4.4 mais aussi § 4.5.
L’ensemble des hypothèses énoncées dans la description de l’environnement de sécurité de la
TOE doit être considérée comme constituant les objectifs de sécurité pour l’environnement.
Lorsque les objectifs de sécurité pour l’environnement que constituent les hypothèses
soutiennent spécifiquement des objectifs de sécurité de la TOE, ces hypothèses sont
directement indiquées dans l’argumentaire des objectifs de sécurité de la TOE concernés.
Lorsque les objectifs de sécurité pour l’environnement contrent directement des menaces, ou
lorsque leur soutien est général, cela est présenté à la fin de cette section (§ 4.7).
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 27 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
C I B L E D E S É C U R I T É
4.2 Objectifs de contrôle des flux d’information
O.PCFI_FILTRAGE
La TOE doit fournir un contrôle des flux d’informations entre les réseaux qui
lui sont connectés, en filtrant les flux en fonction de règles paramétrées par
les administrateurs sur la base des caractéristiques suivantes :
L'interface de provenance du flux,
Machines aux extrémités du flux,
Type de protocole IP,
Pour ICMP : type de message,
Pour TCP et UDP : type de service,
Éventuellement : identité de l’utilisateur associée à l’adresse IP source.
Argumentaire : O.PCFI_FILTRAGE est principalement dédié à la satisfaction de la politique
P.FILTRAGE. Il couvre le filtrage en fonction des caractéristiques IP et transport
(P.FILTRAGE.1) et de l’identité de l’utilisateur (P.FILTRAGE.2) spécifiée par cette politique.
O.PCFI_CONTEXTE_APPLICATIF
La TOE doit maintenir des contextes de suivi des sessions applicatives pour
lesquelles des connexions « filles » sont nécessaires, et doit permettre de
n’ouvrir les connexions filles liées à ces sessions que lorsque le contexte
l’exige.
Note : Le cas le plus connu de « connexion fille » est celui des connexions de données FTP,
dont les caractéristiques (port destination) ne peuvent être connues de manière prédéfinie et
résultent du contenu de la session de commande.
Argumentaire : O.PCFI_CONTEXTE_APPLICATIF soutient O.PCFI_FILTRAGE pour couvrir les
aspects « filtrage en fonction des caractéristiques IP et transport » (point 1) de la politique
P.FILTRAGE. En effet, au cours d’une session applicative, les caractéristiques des connexions
filles résultent du contenu de la session. En l’absence de suivi de ce contenu, la politique de
filtrage devrait, dans le doute, autoriser toutes les variations possibles de ces caractéristiques
pour que les protocoles applicatifs considérés puissent fonctionner. Cet objectif permet donc
d’appliquer une politique de filtrage la plus restrictive possible.
O.PCFI_I&A_UTIL
La TOE doit permettre d’exiger que les utilisateurs soient identifiés et
authentifiés avant de leur accorder l’accès à certains services qui leur sont
autorisés.
Argumentaire : O.PCFI_I&A_UTIL est principalement dédié à la satisfaction de la politique
P.FILTRAGE. Il couvre les exigences d’identification obligatoire et de réussite à l’étape
d’authentification (P.FILTRAGE.2) de cette politique. Il est également dédié à la prévention de la
menace M.UTIL_USURP.
D’autre part, O.PCFI_I&A_UTIL rend difficiles les attaques utilisant l’IP spoofing (M.IP_USURP)
car il permet d’imposer aux attaquants d’usurper l’identité d’un utilisateur et
non celle d’un équipement, pour enfreindre la politique de contrôle des flux
d’information, ce qui revient à réaliser la menace M.UTIL_USURP.
O.PCFI_CHIFFREMENT
La TOE doit fournir des services de type VPN sur les flux échangés avec
certains équipements distants afin d’assurer l’authentification mutuelle des
extrémités, la confidentialité, et l’intégrité de ces flux.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 28 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
45
C I B L E D E S É C U R I T É
Argumentaire : O.PCFI_CHIFFREMENT est principalement dédié à la satisfaction de la
politique P.VPN.
Pour soutenir efficacement cet objectif, il est nécessaire d’empêcher les attaquants potentiels
d’accéder aux clés de session VPN afin d’enfreindre l’objet de la politique P.VPN pour ce flux
chiffré (le déchiffrer a posteriori, ou bien le modifier, le rejouer, ou y insérer des données). Cette
protection est assurée :
 du côté de la TOE, par HP_PROTECT_BOITIERS qui empêche un accès physique aux
boîtiers,
 du côté des correspondants VPN par HTI.PROTECT_CORRESP_VPN et
HTI.PROTECT_CLIENTS_VPN, selon que ces correspondants VPN sont des équipements
réseau fixes ou des postes clients nomades.
L’application d’une politique de chiffrement est le moyen le plus efficace de contrer l’usurpation
d’adresse IP (M.IP_USURP), en imposant une authentification forte des entités aux extrémités
du flux d’information. Cf. O.IPS_DETECTION_ATTAQUES et O.PCFI_I&A_UTIL pour les cas
où la mise en place d’une politique de chiffrement n’est pas réalisable pour contrer cette
menace.
De même, dans le cas où l’établissement des sessions VPN permet de garantir l’identité des
utilisateurs (par opposition à celle des équipements), cet objectif permet de contrer
M.UTIL_USURP.
O.JAA_PCFI2
La TOE doit :
journaliser les événements se rapportant à l’application de la politique de
contrôle des flux d’information (filtrage et chiffrement),
permettre d’auditer les traces d’enregistrement de ces événements,
et remonter des alarmes à l’administrateur en cas de détection
d’événements spécifiés comme critiques par ce dernier.
Argumentaire : O.JAA_PCFI est principalement dédié à la satisfaction de la politique
P.AUDIT_ALARME. Il couvre l’aspect « enregistrement des événements de filtrage et de
chiffrement jugés sensibles par l’administrateur » (P.AUDIT_ALARME.1).
O.PCFI_HORAIRE
La TOE doit être capable d’appliquer des politiques de filtrage différentes
selon l’heure et le jour considéré.
Argumentaire : O.PCFI_HORAIRE est dédié à la satisfaction de la politique P.FILTRAGE. Il
couvre la variabilité du filtrage en fonction de la date et de l’heure (P.FILTRAGE.3) spécifiée par
cette politique.
2
‘JAA’ = journalisation, audit et alarmes.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 29 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
4.3 Objectifs de protection contre les attaques Internet
O.IPS_DETECTION_ATTAQUES
La TOE doit être capable d’analyser les paquets associés aux flux
d’information, ainsi que les requêtes / commandes / réponses applicatives
incluses dans ces flux, afin de détecter et de rejeter des attaques sur les
équipements des réseaux de confiance.
Argumentaire : O.IPS_DETECTION_ATTAQUES est principalement dédié à la satisfaction de la
politique P.ANALYSE. La détection des attaques couvre notamment la corrélation entre
l’adresse IP des paquets entrants et l’interface sur laquelle ils se présentent, ce qui permet de
contrer les tentatives d’usurpation d’adresse IP (M.IP_USURP) menée avec des adresses non
comprises dans la plage associée à l’interface de réception.
Note : Tous les flux autorisés à passer la TOE sont analysés même ceux qui sont à destination
de celle-ci. Ce cas est particulier et n'est pas l'objectif de la formulation de
O.IPS_DETECTION_ATTAQUES.
O.IPS_CONFORMITE_RFC
La TOE doit être capable d’analyser les paquets associés aux flux
d’information, ainsi que les requêtes / commandes / réponses applicatives
incluses dans ces flux afin de détecter et de rejeter les paquets et les flux
applicatifs non conformes aux RFC.
Argumentaire : O.IPS_CONFORMITE_RFC est dédié à la satisfaction de la politique
P.ANALYSE, particulièrement la prévention des infractions aux bonnes pratiques
(P.ANALYSE.2).
O.JAA_IPS
La TOE doit :
journaliser les événements se rapportant à la détection des intrusions
potentielles,
permettre d’auditer les traces d’enregistrement de ces événements,
et remonter des alarmes à l’administrateur en cas de détection
d’événements spécifiés comme critiques par ce dernier.
Argumentaire : O.JAA_IPS est principalement dédié à la satisfaction de la politique
P.AUDIT_ALARME. Il couvre les aspects de cette politique spécifiquement associés à la prise
en compte des intrusions potentielles. Cet objectif soutient O.IPS_DETECTION_ATTAQUES et
O.IPS_CONFORMITE_RFC en fournissant le moyen de contrôler a posteriori l’efficacité de la
configuration des fonctions de prévention des intrusions, ainsi que de reconnaître d’éventuels
faux positifs comme tels.
O.RESIST_AUTH_UTIL
La TOE doit fournir des mécanismes d’authentification qui empêchent que la
réutilisation de données provenant de l’authentification d’utilisateurs
autorisés et/ou la contrefaçon de données d’authentification permette à un
attaquant d’usurper l’identité d’un utilisateur autorisé.
Argumentaire : O.RESIST_AUTH_UTIL est dédié à la prévention de la menace
M.UTIL_USURP. Dans le cas où l’exigence d’identification / authentification des utilisateurs est
la stratégie sélectionnée pour contrer les attaques basées sur l’usurpation d’adresse IP, cet
objectif soutient également O.PCFI_I&A_UTIL pour contrer M.IP_USURP.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 30 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
4.4 Objectifs de prévention de l’utilisation impropre
O.PCAOA
La TOE doit contrôler l’accès des administrateurs aux opérations
d’administration de la sécurité en fonction de droits individuels associés à
différentes tâches d’administration.
Argumentaire : O.PCAOA est dédié :
 à la prévention de lM.MAUVAIS_USAGE, puisqu’il permet d’implémenter une séparation
des tâches adaptée à la responsabilité et à la compétence de chaque administrateur,
 à la prévention des opérations d’administration illicites (M.ADMIN_ILLICITE), puisqu’il
permet de prévenir certaines opérations d’administration illicites (celles pour lesquelles un
contrôle d’accès est techniquement réalisable, cf. O.JAA_PCAOA).
O.PCAOA_I&A_ADMIN
La TOE doit exiger que les administrateurs soient identifiés et authentifiés
avant de leur accorder l’accès aux fonctions d’administration de la sécurité.
Argumentaire : O.PCAOA_I&A_ADMIN fournit les moyens de baser le contrôle d’accès spécifié
par O.PCAOA et l’imputabilité spécifiée par O.JAA_PCAOA sur l’identité des administrateurs,
afin de contrer M.MAUVAIS_USAGE et M.ADMIN_ILLICITE.
O.JAA_PCAOA
La TOE doit :
journaliser les événements se rapportant aux opérations d’administration
de la sécurité effectuées par chaque administrateur autorisé,
permettre d’auditer et d'imputer les traces d’enregistrement de ces
événements,
journaliser et remonter des alarmes à l’administrateur en cas de
détection d’événements spécifiés comme critiques par ce dernier et
notamment les tentatives d’ouverture de session d’administration non
autorisées.
Argumentaire : Dans de nombreux contextes d’exploitation, il ne sera pas souhaitable ou
techniquement possible d’empêcher les administrateurs d’effectuer certaines opérations
d’administration de la sécurité, mais plutôt de les former et de les responsabiliser aux effets de
ces opérations, tout en s’assurant a posteriori qu’ils les effectuent à bon escient. C’est en ce
sens que O.JAA_PCAOA, avec le soutien de HH.PERSONNEL, complète O.PCAOA lorsque la
prévention de M.MAUVAIS_USAGE et M.ADMIN_ILLICITE n’est pas réalisable par un contrôle
d’accès technique aux opérations d’administration de la sécurité.
O.SAUVEGARDE_RESTAURATION
La TOE doit fournir des moyens de sauvegarder la configuration courante de
ses fonctions de sécurité, et de restaurer celle-ci ultérieurement.
Argumentaire : O.SAUVEGARDE_RESTAURATION contribue à la prévention de l’utilisation
impropre (M.MAUVAIS_USAGE) en permettant de conserver et de restaurer des configurations
types validées par rapport à des problématiques de sécurité bien définies, et de revenir en
arrière en cas d’erreur de manipulation. Cet objectif est dédié à la satisfaction de la politique
P.SAUVEGARDE_RESTAURATION.
O.QUALITE_DOC
Les possibilités d'erreurs accidentelles sont réduites grâce à la qualité des
documents d'exploitation à destination de l'administrateur qui est contrôlée
spécifiquement sous l'angle des risques de mauvaise utilisation de la TOE.
Argumentaire : O.QUALITE_DOC est dédié à la prévention de M.MAUVAIS_USAGE.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 31 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
45
C I B L E D E S É C U R I T É
4.5 Objectifs de protection de la TOE
O.RESIST_AUTH_ADMIN
La TOE doit fournir des mécanismes d'authentification qui empêchent que la
réutilisation de données provenant de l'authentification d'administrateurs
autorisés à se connecter à distance et/ou la contrefaçon de données
d'authentification permette à un attaquant d'usurper l'identité d'un
administrateur autorisé.
Argumentaire : O.RESIST_AUTH_ADMIN est dédié à la prévention de la menace
M.ADMIN_USURP, qui est un prérequis possible pour la réalisation de M.ADMIN_ILLICITE.
O.PROTECT_JOURN
La TOE doit pouvoir mettre en œuvre des fonctions de rotation des fichiers
de trace des événements de sécurité, d'arrêt de l'enregistrement de ces
événements ou de blocage total des flux lorsqu'une saturation potentielle des
fichiers survient.
Argumentaire : O.PROTECT_JOURN est dédié à la prévention de la menace
M.PERTE_AUDIT. Il soutient les objectifs O.JAA_PCFI, O.JAA_IPS et O.JAA_PCAOA pour
contrer les infractions à la politique P.AUDIT_ALARME et contrer les menaces
M.MAUVAIS_USAGE et M.ADMIN_ILLICITE.
O.PROTECT_SESSIONS_ADMIN
La TOE doit protéger le contenu des sessions d'administration à distance
contre les tentatives de visualisation, d'altération, de suppression par des
attaquants.
Argumentaire : O.PROTECT_SESSIONS_ADMIN est dédié à la prévention de la menace
M.SESSION_ADMIN_ILLICITE, qui est un prérequis possible pour la réalisation de
M.ADMIN_ILLICITE.
4.6 Autres objectifs de soutien des mesures d’assurance sécurité
O.CONFORMITE_FONCTIONS
Les procédures de l’environnement de développement garantissent que les
fonctions de sécurité de la TOE sont développées conformément à leurs
spécifications.
Argumentaire : O.CONFORMITE_FONCTIONS vise à éliminer les erreurs d’implémentation des
fonctions de sécurité de la TOE vis-à-vis des objectifs de sécurité spécifiés pour la TOE. En ce
sens, il soutient tous ces objectifs pour contrer les menaces et satisfaire les règles de la
politique de sécurité
O.EFFICACITE_FONCTIONS
Les fonctions de sécurité de la TOE et leurs documents de développement
sont contrôlés spécifiquement sous l’angle de l’existence de vulnérabilités
permettant la réalisation de menaces et/ou d’infractions aux règles de la
politique de sécurité.
Argumentaire : O.EFFICACITE_FONCTIONS permet de confirmer, à travers un contrôle détaillé
incluant des revues de documents de développement et des tests de la TOE, que les fonctions
de sécurité spécifiées pour la TOE dans le présent document répondent bien à la problématique
de sécurité énoncée. En ce sens, il soutient tous les objectifs de sécurité spécifiés pour la TOE
pour contrer les menaces et satisfaire les règles de la politique de sécurité.
O.INTEGRITE_TOE
Les procédures de l’environnement de développement préviennent le risque
de modification accidentelle ou intentionnelle de la TOE au cours de son
cycle de développement et jusqu’à sa livraison sur les sites d’exploitation.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 32 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
45
C I B L E D E S É C U R I T É
Argumentaire : O.INTEGRITE_TOE garantit que la TOE qui parvient aux sites d’exploitation
fournit effectivement les fonctions de sécurité prévues. En ce sens, il soutient tous les objectifs
de sécurité spécifiés pour la TOE pour contrer les menaces et satisfaire les règles de la
politique de sécurité.
O.CONFIDENTIALITE_TOE
Les procédures de l’environnement de développement préviennent le risque
de divulgation d’informations sensibles concernant le développement de la
TOE.
Argumentaire : O.CONFIDENTIALITE_TOE rend plus difficile aux attaquants la mise en œuvre
de vulnérabilités éventuelles de la TOE nécessitant la connaissance d’informations sensibles,
dont on peut supposer qu’elles pourraient avoir un impact critique sur la sécurité.
O.CONFIDENTIALITE_TOE soutient donc tous les objectifs de sécurité spécifiés pour la TOE
pour contrer les menaces et satisfaire les règles de la politique de sécurité.
4.7 Objectifs de sécurité pour l’environnement
HP.PROTECT_BOITIERS
Argumentaire : Cet objectif de sécurité est dédié à la prévention de l'aspect physique de
M.ADMIN_ILLICITE. Il élimine les possibilités d’effectuer des opérations d’administration de la
sécurité illicites à partir d’un accès local aux boîtiers appliances firewall-VPN en l’absence du
super-administrateur.
HO.SUPER_ADMIN
Argumentaire :
 La centralisation, entre les mains du super-administrateur, de la capacité de procéder à
l’installation ou à la maintenance des boîtiers firewall-VPN (HO.SUPER_ADMIN.1) a pour
effet de garantir un fonctionnement correct des fonctions de sécurité de la TOE en général.
HO.SUPER_ADMIN.1 soutient donc tous les objectifs de sécurité spécifiés pour la TOE
pour contrer les menaces et satisfaire les règles de la politique de sécurité.
 La centralisation, entre les mains du super-administrateur, de la capacité d’implémenter la
politique de séparation des tâches d’administration (HO.SUPER_ADMIN.2) a pour effet de
garantir un fonctionnement correct des fonctions de sécurité dédiées à O.PCAOA et
O.JAA_PCAOA. HO.SUPER_ADMIN.2 soutient donc ces objectifs de sécurité spécifiés
pour la TOE pour contrer les menaces M.MAUVAIS_USAGE et M.ADMIN_ILLICITE.
 Par ailleurs, le fait que toutes les interventions dans les locaux où sont stockés les boîtiers
appliances firewall-VPN se fassent sous la surveillance et la responsabilité du super-
administrateur (HO.SUPER_ADMIN.3) élimine les possibilités d’effectuer des opérations
d’administration de la sécurité illicites à partir d’un accès local aux boîtiers appliances
firewall-VPN en présence du super-administrateur. HO.SUPER_ADMIN.3 complète donc
HP.PROTECT_BOITIERS pour contrer M.ADMIN_ILLICITE.
HO.MOT_PASSE
Argumentaire : Cet objectif de sécurité soutient O.PCFI_I&A_UTIL pour satisfaire
P.FILTRAGE.2 en garantissant qu’on ne peut pas circonvenir les fonctions d’identification /
authentification des utilisateurs en obtenant le mot de passe d’un utilisateur autorisé. De la
même manière, cet objectif de sécurité soutient O.PCAOA_I&A_ADMIN pour contrer
M.MAUVAIS_USAGE et M.ADMIN_ILLICITE.
HO.BONNE_PCFI
Argumentaire : Cet objectif de sécurité est dédié à la prévention de M.MAUVAIS_USAGE.
HH.PERSONNEL
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 33 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
45
C I B L E D E S É C U R I T É
Argumentaire : Cet objectif de sécurité est dédié à la prévention de M.MAUVAIS_USAGE.
HTI.COUPURE
Argumentaire : Cet objectif de sécurité soutient tous les objectifs de sécurité spécifiés pour
contrer les menaces et satisfaire les règles de la politique de sécurité associées au contrôle des
flux d’information et à la protection contres les attaques Internet, puisqu’il permet d’éviter le
contournement des fonctions de sécurité dédiées à ces objectifs en interdisant l’établissement
de flux d’information soumis à la PCFI mais qui, du fait qu’ils ne passent par aucun des boîtiers
appliances firewall-VPN, ne seraient pas soumis à ces fonctions de sécurité.
HTI.USAGE_STRICT
Argumentaire : Cet objectif de sécurité est dédié à la prévention de M.ADMIN_ILLICITE. Il
élimine la possibilité d’effectuer des opérations d’administration de la sécurité illicites, ou de
modifier le comportement des boîtiers appliances firewall-VPN de toute autre manière, à travers
un accès détourné basé sur d’éventuelles vulnérabilités de logiciels non soumis à l’évaluation
s’exécutant sur les boîtiers. L’interdiction des protocoles autres qu’IP (AppleTalk, IPX, etc.)
permet d’empêcher le contournement de la politique de contrôle des flux d’information d’une
manière similaire à H.COUPURE.
HTI.AUTONOME
Argumentaire : Cet objectif de sécurité élimine le risque de contournement des fonctions de
sécurité à travers l’intrusion ou la substitution d’équipements externes dont dépendrait la TOE
pour remplir ses fonctions. Il soutient donc tous les objectifs de sécurité spécifiés pour la TOE
pour contrer les menaces et satisfaire les règles de la politique de sécurité.
HTI.PROTECT_STATIONS
Argumentaire : Cet objectif de sécurité est dédié à la prévention de M.ADMIN_ILLICITE.
HTI.PROTECT_CORRESP_VPN
Argumentaire : Cet objectif de sécurité soutient O.PCFI_CHIFFREMENT pour satisfaire P.VPN
en garantissant que l’objet de la politique de chiffrement (la protection en confidentialité et en
intégrité des flux d’information) ne peut être contourné à travers la récupération des clés de
session sur les équipements distants.
HTI.PROTECT_CLIENTS_VPN
Argumentaire : Cet objectif de sécurité soutient O.PCFI_CHIFFREMENT pour satisfaire P.VPN
en garantissant que l’objet de la politique de chiffrement (la protection en confidentialité et en
intégrité des flux d’information) ne peut être contourné à travers la récupération des clés de
session sur les postes clients.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 34 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
C I B L E D E S É C U R I T É
4.8 Argumentaire des objectifs de sécurité
La prévention des menaces et la satisfaction des règles de la politique de sécurité par les
objectifs de sécurité est exprimée dans les rubriques « argumentaire » qui accompagnent
l’énoncé de chaque objectif de sécurité. Le lien entre les objectifs de sécurité et les menaces ou
les règles de la politique de sécurité est résumé ci-dessous.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 35 de 109 Référence : na_tn_ciblesec_fr.sxw
5
C I B L E D E S É C U R I T É
P.FILTRAGE
1
:
caractéristiques
IP
2
:
identité
de
l’utilisateur
3
:
date
et
heure
P.VPN
P.AUDIT_ALARME
P.ANALYSE
M.IP_USURP
M.UTIL_USURP
M.MAUVAIS_USAGE
P.SAUVEGARDE_RESTAURATION
M.ADMIN_ILLICITE
M.ADMIN_USURP
M.SESSION_ADMIN_ILLICITE
M.PERTE_AUDIT
O.PCFI_FILTRAGE X X
O.PCFI_CONTEXTE_APPLICATIF S
O.PCFI_I&A_UTIL X X X
O.PCFI_CHIFFREMENT X X X
O.JAA_PCFI X
O.PCFI_HORAIRE X
O.IPS_DETECTION_ATTAQUES X X
O.IPS_CONFORMITE_RFC X
O.JAA_IPS X S S
O.RESIST_AUTH_UTIL S X
O.PCAOA X X
O.PCAOA_I&A_ADMIN X X
O.JAA_PCAOA X X
O.SAUVEGARDE_RESTAURATION X X
O.QUALITE_DOC X
O.RESIST_AUTH_ADMIN X X
O.PROTECT_JOURN S S S X
O.PROTECT_SESSIONS_ADMIN X X
O.CONFORMITE_FONCTIONS S S S S S S S S S S S S S S
O.EFFICACITE_FONCTIONS S S S S S S S S S S S S S S
O.INTEGRITE_TOE S S S S S S S S S S S S S S
O.CONFIDENTIALITE_TOE S S S S S S S S S S S S S S
HP.PROTECT_BOITIERS X
HO.SUPER_ADMIN
1 S S S S S S S S S S S S S S
2 S S
3 S
HO.MOT_PASSE S S S
HO.BONNE_PCFI S
HH.PERSONNEL S
HTI.COUPURE S S S S S S S S
HTI.USAGE_STRICT S S S S S S S S S
HTI.AUTONOME S S S S S S S S S S S S S S
HTI.PROTECT_STATIONS S
HTI.PROTECT_CORRESP_VPN S
HTI.PROTECT_CLIENTS_VPN S
Légende : X : l’objectif est dédié à la prévention de la menace / la satisfaction de la règle de la politique de sécurité.
S : l’objectif soutient d’autres objectifs pour prévenir les menaces / satisfaire les règles de la politique de sécurité.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 36 de 109 Référence : na_tn_ciblesec_fr.sxw
C I B L E D E S É C U R I T É
5 EXIGENCES DE SÉCURITÉ DES TI
Le but de cette section est de présenter les exigences de sécurité des TI, qui
Le but de cette section est de présenter les exigences de sécurité des TI, qui
résultent du raffinement des objectifs de sécurité, ainsi qu'un argumentaire
résultent du raffinement des objectifs de sécurité, ainsi qu'un argumentaire
démontrant que ce raffinement a été correctement effectué.
démontrant que ce raffinement a été correctement effectué.
Les exigences de sécurité des TI comprennent les exigences de sécurité pour la
Les exigences de sécurité des TI comprennent les exigences de sécurité pour la
TOE et les exigences de sécurité pour l'environnement qui, si elles sont
TOE et les exigences de sécurité pour l'environnement qui, si elles sont
satisfaites, garantiront que la TOE peut satisfaire à ses objectifs de sécurité.
satisfaites, garantiront que la TOE peut satisfaire à ses objectifs de sécurité.
Les CC répartissent les exigences de sécurité en deux catégories : exigences
Les CC répartissent les exigences de sécurité en deux catégories : exigences
fonctionnelles et exigences d'assurance. Les exigences fonctionnelles portent sur
fonctionnelles et exigences d'assurance. Les exigences fonctionnelles portent sur
les fonctions de la TOE qui contribuent spécifiquement à la sécurité des TI et qui
les fonctions de la TOE qui contribuent spécifiquement à la sécurité des TI et qui
garantissent le comportement souhaité en terme de sécurité. Les exigences
garantissent le comportement souhaité en terme de sécurité. Les exigences
d'assurance portent sur les actions à effectuer par le développeur, les éléments
d'assurance portent sur les actions à effectuer par le développeur, les éléments
de preuve à produire et les actions à effectuer par l'évaluateur.
de preuve à produire et les actions à effectuer par l'évaluateur.
5.1 Introduction
5.1.1 Généralités
Les exigences fonctionnelles de sécurité de la TOE ont été réparties dans les sous-ensembles
fonctionnels suivants :
Protection contre
les attaques
Internet
Prévention de l’utilisation impropre et protection de
la TOE
Contrôle des flux d’information
Fonctions de
filtrage
Fonctions de
chiffrement
Fonctions
d’identification /
authentification
Fonctions
d’établissement
des SA
Fonctions de journalisation, d’audit et d’alarme
Fonctions de programmation h oraire
Fonctions de
prévention des
intrusions
Fonctions de contrôle
d’accès aux opérations
d’administration de la
sécurité
Fonctions de
sauvegarde et
de
restauration
Fonctions de protection
des sessions
d’administration
Autres fonctions de soutien
5.1.2 Conventions typographiques
Afin de présenter des exigences de sécurité faciles à lire et à utiliser, celles-ci ont été rédigées
en français, en s’aidant de la traduction française des Critères Communs, et un effort a été
accompli pour transposer les notions Critères Communs (comme « la TSF » ou « les sujets et
les objets ») dans des termes correspondant au produit, par le jeu des opérations d’affectation,
de sélection et de raffinement des Critères Communs. Les opérations n’ont pas été identifiées
dans le texte des exigences de cette section, les libellés qui résultent de leur application sont
seulement signalés en gras.
Or, seul l’énoncé en anglais extrait de [CC-02] et [CC-03] a une valeur normative et tient lieu de
référence. De plus, les opérations effectuées doivent être précisément identifiées. L’annexe B,
§ , a été spécialement rédigée à cet effet et constitue l’élément de preuve à prendre en compte
comme énoncé des exigences de sécurité des TI.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 37 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
C I B L E D E S É C U R I T É
Les exigences de sécurité explicitement énoncées ont également été spécifiées initialement en
anglais puis traduites dans cette section. L’annexe C, § 9, présente ces exigences de sécurité
explicitement énoncées sous un format similaire à celui de [CC-02].
Format des étiquettes des exigences de sécurité :
 Les exigences d’assurance sécurité ont des étiquettes identiques à celles utilisées dans
[CC-03] ;
 Les exigences fonctionnelles de sécurité ont des étiquettes au format suivant :
FCC_FFF.composant.<itération.>n
 FCC est le trigramme de la classe ;
 FFF est le trigramme de la famille ;
 composant est l’identifiant du composant : soit un numéro pour les composants extraits
de [CC-02], soit un trigramme pour les exigences de sécurité explicitement énoncées ;
 itération est une étiquette permettant d’identifier les différentes itérations d’un même
composant à l’intérieur de différents ensembles fonctionnels ;
 n est le numéro d’élément.
5.1.3 Présentation des données de sécurité
5.1.3.1 Attributs des paquets IP sur lesquels portent les règles de filtrage et de chiffrement
 L’interface de réception du paquet ;
 L’adresse IP source et destination du paquet et, partant de là, la machine source et la
machine destination du paquet ;
 Le numéro de protocole IP ;
 L’index de sécurité ESP ;
 Le port source et destination TCP/UDP ou le type de message ICMP ;
 Si l’utilisateur s’est préalablement identifié et authentifié, l’identité déclarée par l’utilisateur.
5.1.3.2 Notion de slot
Le comportement des fonctions de sécurité est décrit à l’aide de « slots », qui sont une
représentation abstraite et interprétable par les administrateurs des fichiers de configuration du
boîtier appliance firewall-VPN. Les slots décrivent des comportements de sécurité bien définis,
pouvant être sauvegardés et réutilisés. Ils peuvent être activés à la demande et servent
également à construire les échéanciers de programmation horaire des fonctions de filtrage.
Dans le cadre de l’évaluation, nous nous intéressons à deux types de slots : les slots de filtrage
et les slots de chiffrement (aussi appelés « slots VPN »).
 Un slot de filtrage est une liste de règles de filtrage. Lorsque le boîtier appliance firewall-
VPN fonctionne, il y en a toujours un actif.
 Un slot de chiffrement est un ensemble de tunnels VPN.
5.1.3.3 Paramètres des règles de filtrage
 L’identifiant de la règle ;
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 38 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
 (critère) L’interface de réception des paquets IP couverts par la règle ;
 (critère) La ou les machines à l’origine des flux d’information couverts par la règle ;
 (critère) Le ou les protocoles IP, les services TCP/UDP ou les types de messages ICMP des
flux d’information couverts par la règle ;
 (critère) La ou les machines destinataires des flux d’information couverts par la règle ;
 (critère) L’authentification des utilisateurs et éventuellement l’utilisateur ou le groupe
d’utilisateurs autorisés par la règle ;
 L’action : ‘aucune’, ‘passer’, ‘bloquer’, ‘réinitialiser’ ;
 La génération d’un enregistrement d’audit et le niveau d’alarme éventuellement attribué ;
 La bande passante maximale allouée aux flux couverts par la règle ;
 Le taux maximum d’ouverture connexions / pseudo-connexions associé à la règle.
5.1.3.4 Paramètres d’une connexion / pseudo connexion
 (critère) L’adresse IP source, l’adresse IP destination ;
 (critère) Le type de protocole (TCP, UDP ou ICMP) ;
 (critère) Pour TCP et UDP : les ports source et destination ;
 (critère) Pour ICMP : les champs ‘type’ et ‘code’ du message ICMP ;
 Pour UDP et ICMP : l’âge de la pseudo connexion ;
 Pour TCP : l’état de la connexion, les fenêtres (dans le but de rejeter les paquets non
conformes).
5.1.3.5 Caractéristiques des utilisateurs
 Le nom de login de l’utilisateur ;
 Des renseignements sur l’utilisateur (nom, prénom, téléphone, mail, etc.) ;
 Le fait que l’utilisateur soit autorisé à s’authentifier (on peut révoquer un utilisateur sans
supprimer son compte) ;
 Le mécanisme d’authentification3
;
 Le mot de passe de référence.
5.1.3.6 Table des utilisateurs authentifiés
 Le nom de login de l’utilisateur ;
 L’adresse IP de la machine depuis laquelle il s’est authentifié ;
 La durée restante avant que l’authentification n’expire.
3
Obligatoirement SRP dans le mode d’utilisation soumis à l’évaluation.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 39 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
C I B L E D E S É C U R I T É
5.1.3.7 Paramètres des tunnels VPN
Un tunnel VPN consiste en un chemin de confiance (la SA ISAKMP) entre l’IPS-Firewall et un
correspondant VPN, ainsi qu’un ensemble de règles de chiffrement à appliquer aux flux
d’information qui doivent passer par le tunnel. L’application de ces règles nécessite la
négociation et l’établissement de contextes de sécurité qui sont les SA IPSec.
Les paramètres des tunnels VPN sont les suivants :
 L’interface locale sur laquelle le tunnel doit être mis en œuvre ;
 L’adresse IP de l’autre extrémité du tunnel (le correspondant VPN) ;
 Le mécanisme d’authentification mutuelle : clé pré-partagée (PSK) ou certificats (PKI) ;
 En cas d’authentification par certificat : le certificat X509 présenté par l’IPS-Firewall ;
 En cas d’authentification par clé pré-partagée : l’identité déclarée par l’IPS-Firewall : adresse
IP, adresse e-mail ou nom de domaine complet (fully qualified domain name) ;
 Les règles de chiffrement associées au tunnel ;
 La paire de SA ISAKMP courantes associée au tunnel VPN.
5.1.3.8 Paramètres d’une SA ISAKMP
 Le correspondant VPN ;
 L’âge actuel de la SA ;
 Sa durée de vie ;
 L’algorithme d’authentification effectif, et sa clé ;
 L’algorithme de chiffrement effectif, et sa clé ;
5.1.3.9 Règle de chiffrement (entrée de SPD)
 (critère) La ou les machines locales couvertes par la règle ;
 (critère) La ou les machines distantes couvertes par la règle ;
 (critère) Le type de protocole couvert par la règle ;
 Les propositions acceptables lors de la négociation des SA :
 Algorithmes d’authentification et tailles des clés ;
 Algorithmes de chiffrement et tailles des clés ;
 Durée de vie des SA.
 Les paires de SA IPSec courantes associées à la règle.
5.1.3.10 Paramètres d’une SA IPSec
 (critère) L’index de sécurité (SPI – Security Parameter Index) ;
 L’âge actuel de la SA ;
 Sa durée de vie ;
 Le caractère entrant ou sortant ;
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 40 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
C I B L E D E S É C U R I T É
 L’algorithme d’authentification effectif, et sa clé ;
 L’algorithme de chiffrement effectif, et sa clé.
5.1.3.11 Caractéristiques des correspondants VPN gérées par l’IPS-Firewall
 Soit un certificat X509 ou une CA (avec la CRL associée) dans cas de l’authentification par
certificat,
 Soit un identifiant (adresse IP, adresse e-mail ou nom de domaine complet), associé à une
clé pré-partagée.
5.1.3.12 Profil des attaques Internet
 Le libellé ;
 L’action associée : bloquer ou laisser passer le paquet (pas toujours configurable) ;
 Le niveau d’alarme désiré: ignorée, mineure ou majeure.
5.1.3.13 Profil des événements système
 Le libellé ;
 Le niveau d’alarme désiré: ignorée, mineure, majeure ou système.
5.1.3.14 Réception des alarmes par mail
 Les niveaux d’alarme concernés : aucunes, majeures seulement ou majeurs et mineures ;
 Le regroupement éventuel de plusieurs alarmes dans un seul mail, et le cas échéant, la
période de regroupement ;
 Les adresses e-mail des destinataires.
5.1.3.15 Caractéristiques des administrateurs
Les administrateurs sont gérés dans la même base locale que les utilisateurs non administratifs,
mais on leur attribue en plus un rôle administrateur explicite, ainsi qu’un profil construit à partir
d’un droit de modification (‘M’) et de droits associés à différents domaines de gestion de la
sécurité :
 ‘L’ : log et monitor (i.e. accès aux fichiers de trace et aux fonctions d’audit),
 ‘F’ : filtrage,
 ‘V’ : VPN,
 ‘U’ : utilisateurs,
 ‘O’ : objets (de configuration du réseau),
 ‘*’ : autres.
On utilise le terme ‘auditeur’ pour désigner les administrateurs chargés d’effectuer les audits et
de gérer les traces d’audit. Ces auditeurs sont des administrateurs possédant le droits ‘L’.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 41 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
C I B L E D E S É C U R I T É
5.2 Exigences de sécurité pour la TOE
Cette section présente le raffinement des exigences fonctionnelles de la TOE. La description
formelle de ces exigences figure au chapitre 8. Pour assurer la traçabilité, on indique ici le titre
des exigences fonctionnelles concernées entre crochets (ex : [FDP_IFC.2.1]).
5.2.1 Exigences de contrôle des flux d’information
5.2.1.1 Fonctions de filtrage
5.2.1.1.1 FDP_IFC.2 – Filtrage complet des flux d’information
[FDP_IFC.2.1] Les fonctions de filtrage doivent appliquer la politique de filtrage aux
paquets IP entrants.
[FDP_IFC.2.2] Les fonctions de filtrage doivent garantir que tous les paquets IP
entrants sont couverts par la politique de filtrage.
Argumentaire : FDP_IFC.2 soutient FDP_IFF.1.Filtrage pour satisfaire O.PCFI_FILTRAGE, en
définissant la politique de filtrage et en exigeant qu’elle s’applique à tous les paquets IP
entrants.
5.2.1.1.2 FDP_IFF.1.Filtrage – Fonctions de filtrage
[FDP_IFF.1.Filtrage.1]
Les fonctions de filtrage doivent appliquer la politique de filtrage en
fonction des types suivants d'attributs de sécurité des paquets IP entrants :
L’interface de réception,
L’adresse IP source et destination du paquet et, partant de là, la
machine source et la machine destination du paquet,
Le numéro de protocole IP,
Si le protocole est TCP ou UDP : le port source et destination,
Si le protocole est ICMP : les champs ‘type’ et ‘code’ du message ,
Si l’adresse IP source est associée à un utilisateur dans la table des
utilisateurs authentifiés : l’identité de l’utilisateur.
[FDP_IFF.1.Filtrage.2]
Les fonctions de filtrage doivent autoriser un paquet IP entrant si les
règles suivantes s'appliquent :
Préalablement à l’application des règles de filtrage, le paquet est
comparé à l’ensemble des connexions / pseudo-connexions
actuellement établies et ayant été autorisées par les règles de
filtrage ;
Si le paquet correspond à une de ces connexions / pseudo-
connexions, il est autorisé à passer sans être soumis aux règles de
filtrage ;
Sinon, le paquet est autorisé si l’action de la première règle de
filtrage applicable est ‘passer’.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 42 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
[FDP_IFF.1.Filtrage.3]
Les fonctions de filtrage doivent appliquer la règle complémentaire
suivante : les règles de filtrage dont l’action est ‘aucune’ ont pour
unique objet la génération d’enregistrements d’audit et ne rentrent pas
en compte dans le filtrage des paquets.
[FDP_IFF.1.Filtrage.4]
(sans objet)
[FDP_IFF.1.Filtrage.5]
Les fonctions de filtrage doivent autoriser explicitement un paquet IP
entrant en fonction des règles suivantes :
Les sessions associées à des protocoles nécessitant des
connexions filles sont suivies de manière à autoriser ces
connexions filles conformément à l’état de la session principale ;
Des règles de filtrage implicites peuvent être générées par le
firewall en liaison avec la configuration d’autres fonctions de
sécurité. Ce sont les règles correspondant à :
i. l’administration à distance du firewall,
ii. l’authentification des utilisateurs,
iii. l’établissement de VPN.
[FDP_IFF.1.Filtrage.6]
Les fonctions de filtrage doivent interdire explicitement un paquet IP
entrant en fonction des règles suivantes :
L’action de la première règle de filtrage applicable est ‘bloquer’ ou
‘réinitialiser’ ;
Aucune règle de filtrage n’a autorisé le paquet.
Argumentaire : FDP_IFF.1.Filtrage est dédié à la satisfaction de l’objectif O.PCFI_FILTRAGE.
Le point FDP_IFF.1.Filtrage.5.a couvre également l’objectif O.PCFI_CONTEXTE_APPLICATIF.
Enfin, l’objectif O.PCFI_I&A_UTIL est satisfait en spécifiant, pour la ou les machines et les
services sur lesquelles porte l’exigence d’identification / authentification, une règle ‘passer’
couvrant les utilisateurs authentifiés, suivie d’une règle ‘bloquer’ ou ‘réinitialiser’ de portée
identique mais ne couvrant pas les utilisateurs authentifiés. Si l’utilisateur ne s’authentifie pas,
c’est cette dernière règle qui s’appliquera, restreignant ainsi l’accès au service aux utilisateurs
s’étant authentifiés et couverts par la première règle.
5.2.1.2 Fonctions d’identification / authentification
5.2.1.2.1 FIA_UID.2 – Identification de l’utilisateur en vue de l’application de la politique de filtrage
[FIA_UID.2.1]
Les fonctions d’identification / authentification doivent exiger que
chaque utilisateur soit identifié avec succès avant de pouvoir l’ajouter à la
table des utilisateurs authentifiés.
Argumentaire : FIA_UID.2 est dédié à la satisfaction de l’objectif O.PCFI_I&A_UTIL.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 43 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
5.2.1.2.2 FIA_UAU.2 – Authentification de l’utilisateur en vue de l’application de la politique de filtrage
[FIA_UAU.2.1]
Les fonctions d’identification / authentification doivent exiger que
chaque utilisateur soit authentifié avec succès avant de l’ajouter à la table
des utilisateurs authentifiés.
Argumentaire : FIA_UAU.2 est dédié à la satisfaction de l’objectif O.PCFI_I&A_UTIL.
5.2.1.2.3 FIA_UAU.5.Utilisateur – Mécanisme d’authentification des utilisateurs
[FIA_UAU.5.Utilisateur.1]
Les fonctions d’identification / authentification doivent fournir le
mécanisme basé sur le protocole SRP pour contribuer à l’authentification
de l’utilisateur.
[FIA_UAU.5.Utilisateur.2]
Les fonctions d’identification / authentification doivent authentifier
l’identité annoncée de tout utilisateur selon le protocole SRP.
Argumentaire : FIA_UAU.5.Utilisateur soutient FIA_UID.2 et FIA_UAU.2 pour satisfaire l’objectif
O.PCFI_I&A_UTIL. La résistance des mécanismes associés au protocole SRP permet de
satisfaire l’objectif O.RESIST_AUTH_UTIL : la protection contre le rejeu et la contrefaçon des
données d’authentification est garantie par l’utilisation d’un défi / réponse basé sur des clés
éphémères d’entropie supérieure à 2048 bits et générées d’une manière qui empêche les
attaques par référence sur les secrets d’authentification de référence (valeur v de vérification du
mot de passe, cf. [SRP]).
5.2.1.3 Fonctions de chiffrement
5.2.1.3.1 FDP_IFC.1 – Chiffrement des flux d’information
[FDP_IFC.1.1] Les fonctions de chiffrement doivent appliquer la politique de
chiffrement aux datagrammes ESP entrants et aux datagrammes IP
sortants couverts par une règle de chiffrement.
Argumentaire : FDP_IFC.1 soutient FDP_UCT.1, FDP_UIT.1 et FDP_IFF.1.Chiffrement pour
satisfaire O.PCFI_CHIFFREMENT, en définissant la politique de chiffrement.
5.2.1.3.2 FDP_UCT.1 – Confidentialité du contenu des flux
[FDP_UCT.1.1] Les fonctions de chiffrement doivent appliquer la politique de
chiffrement afin de pouvoir transmettre et recevoir des datagrammes IP
d’une façon qui les protège d’une divulgation non autorisée.
Argumentaire : FDP_UCT.1 est dédié à la satisfaction de l’aspect « confidentialité » de l’objectif
O.PCFI_CHIFFREMENT.
5.2.1.3.3 FDP_UIT.1 – Intégrité du contenu des flux
[FDP_UIT.1.1] Les fonctions de chiffrement doivent appliquer la politique de
chiffrement afin de pouvoir transmettre et recevoir des datagrammes IP
d’une façon qui les protège d’erreurs de modification, d’insertion ou de
rejeu.
[FDP_UIT.1.2] Les fonctions de chiffrement doivent pouvoir déterminer lors de la
réception des datagrammes ESP entrants si une modification, une
insertion ou un rejeu a eu lieu.
Argumentaire : FDP_UIT.1 est dédié à la satisfaction de l’aspect « intégrité » de l’objectif
O.PCFI_CHIFFREMENT.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 44 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
5.2.1.3.4 FDP_IFF.1.Chiffrement – Fonctions de chiffrement
[FDP_IFF.1.Chiffrement.1]
Les fonctions de chiffrement doivent appliquer la politique de
chiffrement en fonction des types suivants d'attributs de sécurité des
datagrammes ESP entrants et des datagrammes IP sortants couverts
par une règle de chiffrement :
Datagrammes ESP entrants :
L’index de sécurité (SPI),
Datagrammes IP sortants :
L’adresse IP source et destination du paquet et, partant de là, la
machine source et la machine destination du paquet,
Le type de protocole IP.
[FDP_IFF.1.Chiffrement.2]
Les fonctions de chiffrement doivent autoriser un paquet ESP entrant si
les règles suivantes s'appliquent :
un datagramme ESP entrant est rattachable à une SA IPSec
entrante active,
le paquet encapsulé dans le datagramme ESP correspond aux
critères de la règle de chiffrement associée à la SA IPSec.
[FDP_IFF.1.Chiffrement.3]
Les fonctions de chiffrement doivent doit appliquer la règle
complémentaire suivante : un datagramme IP sortant couvert par une
règle de chiffrement sans SA IPSec sortante active provoque une
tentative de rénégociation. Si la négociation échoue, le datagramme est
détruit.
[FDP_IFF.1.Chiffrement.4]
Les fonctions de chiffrement doivent appliquer aux datagrammes IP
sortants les algorithmes d’authentification et de chiffrement effectifs
spécifiés par la SA IPSec sortante associée à la première règle de
chiffrement applicable.
[FDP_IFF.1.Chiffrement.5]
(sans objet).
[FDP_IFF.1.Chiffrement.6]
(sans objet).
Argumentaire : FDP_IFF.1.Chiffrement soutient FDP_UCT.1, FDP_UIT.1 et
FTP_TRP.1.Corresp pour satisfaire O.PCFI_CHIFFREMENT :
en garantissant que les fonctions de chiffrement et d’authentification sont appliquées aux
datagrammes IP sortants couverts par la politique de chiffrement,
en aiguillant les datagrammes ESP entrants vers les traitements de contrôle d’intégrité et de
déchiffrement spécifiés par la SA IPSec entrant applicable,
en recourant à l’utilisation du chemin de confiance en cas de datagramme IP sortant couvert
par une règle de chiffrement sans SA IPSec sortante applicable.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 45 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
5.2.1.4 Fonctions d’établissement des SA
5.2.1.4.1 FTP_TRP.1.Corresp – Chemin de confiance avec les correspondants VPN
[FTP_TRP.1.Corresp.1]
Les fonctions d’établissement des SA doivent fournir un chemin de
communication entre l’IPS-Firewall et les correspondants VPN qui soit
logiquement distinct des autres chemins de communication et qui garantisse
l’identification de ses extrémités et la protection des données transférées
contre une modification ou une divulgation.
[FTP_TRP.1.Corresp.2]
Les fonctions d’établissement des SA doivent permettre à l’IPS-Firewall
et aux correspondants VPN d’initier une communication via le chemin de
confiance. L’établissement du chemin de confiance correspond à la
phase 1 du protocole IKE.
[FTP_TRP.1.Corresp.3]
Les fonctions d’établissement des SA doivent exiger l’utilisation du
chemin de confiance pour :
l’authentification mutuelle initiale des extrémités du tunnel (phase 1
du protocole IKE),
la négociation des SA IPSec (phase 2 du protocole IKE).
Argumentaire : FTP_TRP.1.Corresp est dédié à la satisfaction de l’aspect « authentification
mutuelle des extrémités » de l’objectif O.PCFI_CHIFFREMENT.
5.2.1.4.2 FIA_UAU.5.Corresp – Multiples mécanismes d’authentification des correspondants VPN
[FIA_UAU.5.Corresp.1]
Les fonctions d’établissement des SA doivent fournir les mécanismes
d’authentification suivants pour contribuer à l’authentification du
correspondant VPN d’un tunnel donné, dans le cadre de
l’authentification mutuelle initiale des extrémités de ce tunnel lors de la
phase 1 IKE :
certificats X509,
clé pré-partagée.
[FIA_UAU.5.Corresp.2]
Les fonctions d’établissement des SA doivent authentifier l’identité
annoncée de tout correspondant VPN selon le mécanisme
d’authentification spécifié pour le tunnel VPN.
Argumentaire : FIA_UAU.5.Corresp soutient FTP_TRP.1.Corresp pour satisfaire l’objectif
O.PCFI_CHIFFREMENT.
5.2.1.4.3 FPT_TDC.1 – Négociation des SA ISAKMP et IPSec
[FPT_TDC.1.1] Les fonctions d’établissement des SA doivent offrir la capacité de
négocier les paramètres des SA ISKAMP et IPSec lors de
l’établissement des tunnels VPN entre l’IPS-Firewall et les
correspondants VPN.
[FPT_TDC.1.2] Les fonctions d’établissement des SA doivent utiliser les règles
suivantes pour négocier les paramètres des SA ISAKMP ou IPSec avec
les correspondants VPN :
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 46 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
Si l’IPS-Firewall est l’initiateur, proposer les paramètres de la SA, et
accepter les réponses aussi rigoureuses qu’une des propositions
faites ;
Si l’IPS-Firewall est le répondeur, n’accepter que les propositions
aussi rigoureuses qu’une des propositions locales.
Argumentaire : FPT_TDC.1 soutient :
d’une part FTP_TRP.1 pour satisfaire les aspects « authentification mutuelle des
extrémités » de l’objectif O.PCFI_CHIFFREMENT, en permettant de négocier les
paramètres qui vont permettre l’authentification mutuelle,
d’autre part FDP_UCT.1 et FDP_UIT.1 pour satisfaire les aspects « confidentialité » et
« intégrité » de l’objectif O.PCFI_CHIFFREMENT en permettant de négocier les paramètres
des algorithmes de chiffrement et d’authentification.
5.2.1.5 Fonctions de journalisation, d’audit et d’alarme
5.2.1.5.1 FAU_GEN.1 – Génération de données d’audit
[FAU_GEN.1.1] Les fonctions de journalisation doivent pouvoir générer un enregistrement
d'audit des événements auditables suivants :
démarrage et arrêt des fonctions de journalisation,
et les événements auditables énumérés dans le tableau ci-dessous
(après FAU_GEN.1.2) :
[FAU_GEN.1.2] Les fonctions de journalisation doivent enregistrer au minimum les
informations suivantes dans chaque enregistrement d'audit :
date et heure de l'événement,
type d'événement,
adresse IP source, et identité de l’utilisateur (si elle est connue),
résultat (succès ou échec) de l’événement ;
niveau d’alarme (si c’en est une) ;
pour chaque type d'événement d'audit, les informations d’audit
complémentaires énoncées dans le tableau ci-dessous :
Composant Événements auditables Informations d’audit
FDP_IFF.1.Filtrage Application d’une règle de filtrage
pour laquelle la génération d’un
enregistrement d’audit est spécifiée.
 Nom de l’interface de réception,
 Action appliquée,
 Identifiant de la règle,
 Type de protocole,
 Type ICMP,
 Port source,
 Adresse IP et port destination.
FIA_UAU.2 Tentative d’authentification.  Si échec : la raison de l’échec.
FTP_TRP.1.Corresp
et FPT_TDC.1
Tentative d’établissement de SA
ISAKMP et IPSec.
 Phase IKE (1 ou 2),
 Si échec : la raison de l’échec
(si possible).
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 47 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
C I B L E D E S É C U R I T É
Composant Événements auditables Informations d’audit
FAU_STG.3 Dépassement de la limite
FAU_SAA.4 Détection d’attaque Internet
potentielle
 Nom de l’interface de réception,
 Action appliquée,
 Libellé de l’attaque,
 Type de protocole,
 Type ICMP,
 Port source,
 Adresse IP et port destination.
FMT_SMR.1,
FMT_MOF.1,
FMT_MTD.1,
FTP_TRP.1.Admin
Accomplissement d’une opération
d’administration de la sécurité (dont
tentative d’ouverture de session
d’administration)
 Type de l’opération,
 Paramètres,
 Identifiant de session
d’administration,
Argumentaire : FAU_GEN.1 est dédié à la satisfaction des aspects « journalisation » (points 1)
des objectifs O.JAA_PCFI, O.JAA_IPS et O.JAA_PCAOA. Pour les événements associés à
FDP_IFF.1.Filtrage et FAU_SAA.4, le résultat (succès ou échec) associé à l’événement
correspond à l’action appliquée par l’IPS-Firewall.
[FAU_GEN.2.1] Les fonctions de journalisation doivent pouvoir associer chaque
événement auditable associé aux opérations d'administration de la
sécurité avec l’identité de l'administrateur qui est à l’origine de
l’événement.
Argumentaire : FAU_GEN.2 est dédié à la satisfaction des aspects « imputabilité » (points 2)
de l'objectif O.JAA_PCAOA.
5.2.1.5.2 FAU_SAR.1 – Revue d’audit
[FAU_SAR.1.1] Les fonctions d’audit doivent offrir aux auditeurs la faculté de lire toutes
les informations d’audit à partir des fichiers de trace.
[FAU_SAR.1.2] Les fonctions d’audit doivent présenter les fichiers de trace d’une façon
permettant à l’auditeur de les interpréter.
Argumentaire : FAU_SAR.1 est dédié à la satisfaction des aspects « audit » (points 2) des
objectifs O.JAA_PCFI, O.JAA_IPS et O.JAA_PCAOA.
5.2.1.5.3 FAU_STG.3 – Action en cas de perte possible de données d’audit
[FAU_STG.3.1] Les fonctions de journalisation doivent entreprendre une action parmi
les suivantes si un fichier de trace dépasse la taille limite maximum
spécifiée :
Rotation des fichiers : les enregistrements d’audit les plus récents
effacent les enregistrements d’audit les plus anciens,
Stopper l'écriture des fichiers : les enregistrements d’audit ne sont
plus mémorisés,
Arrêter le Firewall : l’IPS-Firewall ne s'arrête pas réellement mais il
bloque l'ensemble des flux excepté les sessions d’administration
du Firewall Manager depuis le réseau interne.
Argumentaire : FAU_STG.3 est dédié à la satisfaction de l’objectif O.PROTECT_JOURN.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 48 de 109 Référence : na_tn_ciblesec_fr.sxw
30
35
40
45
50
55
C I B L E D E S É C U R I T É
5.2.1.5.4 FAU_ARP.1.Alarmes – Réponse automatique aux alarmes
[FAU_ARP.1.Alarmes.1]
Les fonctions d’alarme doivent entreprendre les actions suivantes dès la
génération d’un d’enregistrement d’audit auquel est attribué un niveau
d’alarme :
Allumer, si ce n’est pas déjà fait, le voyant correspondant au niveau
d’alarme sur la face avant du boîtier appliance firewall-VPN ;
Transmettre l’alarme aux moniteurs temps-réel connectés ;
Envoyer l’alarme par e-mail aux destinataires spécifiés.
Argumentaire : FAU_ARP.1.Alarmes est dédié à la satisfaction des aspects « remontée
d’alarmes » (points 3) des objectifs O.JAA_PCFI, O.JAA_IPS et O.JAA_PCAOA. On notera que
la dépendance avec FAU_GEN.1 est implicitement satisfaite puisqu'il agit sur des
enregistrements d'audit.
5.2.1.6 Fonctions de programmation horaire
5.2.1.6.1 FMT_MOF.SSB – Programmation horaire du filtrage
[FMT_MOF.SSB.1]
Les fonctions de programmation horaire doivent modifier le
comportement des fonctions de filtrage en fonction de la règle suivante :
le slot de filtrage actif est celui associé par la grille horaire de filtrage à
l'heure et au jour de la semaine courants.
Argumentaire : FMT_MOF.SSB est dédié à la satisfaction de l’objectif O.PCFI_HORAIRE. Le
recours à ce composant explicite a été nécessaire car les composants de [CC-02] ne
permettent pas de spécifier un changement automatique du comportement des fonctions de
sécurité en fonction de la date et de l’heure.
5.2.2 Exigences de protection contre les attaques Internet
5.2.2.1 Fonctions de prévention des intrusions
5.2.2.1.1 FAU_SAA.4 – Heuristiques des attaques complexes
[FAU_SAA.4.1] Les fonctions de prévention des intrusions doivent pouvoir maintenir une
base de connaissance4
des types d'attaque suivants qui peuvent indiquer
une attaque Internet potentielle :
paquets IP dont l’adresse source est incohérente avec l’interface de
réception,
paquets, datagrammes ou segments IP, ICMP, IGMP, TCP ou UDP
non conformes aux RFC, ou utilisation abusive des possibilités
offertes par ces protocoles,
commandes, requêtes ou réponses applicatives non conformes à la
syntaxe générale des commandes / requêtes / réponses définie par
les RFC, ou utilisation abusive des possibilités offertes par ces
protocoles,
attaques basées sur des vulnérabilités connues des serveurs
applicatifs,
4
La base de connaissance est un ensemble de contrôle figé par version de TOE
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 49 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
tentatives de récupération d’information concernant la
configuration des serveurs applicatifs (fingerprinting, port
scanning, etc.),
dépassement du taux d’ouverture de connexions associé à une
règle de filtrage.
[FAU_SAA.4.2] Les fonctions de prévention des intrusions doivent pouvoir comparer
l'état des différents contextes associés à chaque paquet IP entrant et
sortant aux types d'attaque présents dans la base de connaissance.
[FAU_SAA.4.3] Les fonctions de prévention des intrusions doivent être capables
d’indiquer une attaque Internet potentielle quand l'état d'un ou plusieurs
contextes associés à un paquet IP entrant se révèle correspondre à un
type d'attaque présent dans la base de connaissance.
Argumentaire : FAU_SAA.4 est dédié à la satisfaction de l’objectif
O.IPS_DETECTION_ATTAQUES ainsi que la mise en œuvre de la conformité aux RFC
spécifiée par O.IPS_CONFORMITE_RFC (points FAU_SAA.4.1.b et FAU_SAA.4.1.c).
5.2.2.1.2 FAU_ARP.1.IPS – Réponse automatique aux attaques Internet potentielles
[FAU_ARP.1.IPS.1]
Dès la détection d’une attaque Internet potentiellement véhiculée par un
paquet IP entrant, les fonctions de prévention des intrusions doivent :
appliquer au paquet l’action associée au type de l’attaque,
si un niveau d’alarme est spécifié pour ce type d’attaque, générer
un enregistrement d’audit de l’événement, en lui attribuant ce
niveau d’alarme.
Argumentaire : FAU_ARP.1.IPS soutient FAU_SAA.4 pour la satisfaction de l’objectif
O.IPS_DETECTION_ATTAQUES et pour la mise en œuvre de la conformité aux RFC spécifiée
par O.IPS_CONFORMITE_RFC. De plus, FAU_ARP.1.IPS est spécifiquement dédié au point 3
de l’objectif O.JAA_IPS.
5.2.3 Exigences de prévention de l’utilisation impropre
5.2.3.1 Fonctions de contrôle d’accès aux opérations d’administration de la sécurité
5.2.3.1.1 FMT_SMF.1 – Fonctions d'administration de la sécurité
[FMT_SMF.1.1] Les fonctions d'administration de la sécurité doivent être capable de
réaliser les fonctions d'administration de la sécurité suivantes :
Les fonctions de contrôle d’accès aux opérations d’administration
de la sécurité ;
Les fonctions de protection des sessions d’administration
Les fonctions d’audit
Les fonctions de sauvegarde / restauration
Argumentaire : FMT_SMF.1 soutient FMT_MOF.1 et FMT_MTD.1 pour satisfaire à l’objectif de
contrôle d’accès aux opérations d’administration spécifié par O.PCAOA.Il assure également la
mise en oeuvre de FTP_ITT.1, FAU_SAR.1 et FMT_MTD.BRS
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 50 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
5.2.3.1.2 FMT_SMR.1 – Rôle d’administrateur de la sécurité
[FMT_SMR.1.1] Les fonctions de contrôle d’accès aux opérations d’administration de
la sécurité doivent gérer les rôles « administrateur » et
« super administrateur ».
[FMT_SMR.1.2] Les fonctions de contrôle d’accès aux opérations d’administration de
la sécurité doivent être capables d’associer des rôles aux utilisateurs en
fonction des règles suivantes :
Il n’y qu’un seul super-administrateur, distinct des autres
administrateurs, et qui possède tous les droits ;
Les administrateurs sont ceux auxquels on a explicitement attribué
ce rôle.
Argumentaire : FMT_SMR.1 soutient FMT_MOF.1 et FMT_MTD.1 pour satisfaire à l’objectif de
contrôle d’accès aux opérations d’administration spécifié par O.PCAOA.
5.2.3.1.3 FDP_ACC.2 – Contrôle d’accès complet aux opérations d’administration de la sécurité
[FDP_ACC.2.1] Les fonctions de contrôle d’accès aux opérations d’administration de
la sécurité doivent appliquer la politique de contrôle d’accès aux
opérations d’administration de la sécurité à toutes les opérations
d’administration de la sécurité effectuées par l’administrateur.
[FDP_ACC.2.2] Les fonctions de contrôle d’accès aux opérations d’administration de
la sécurité doivent garantir que toutes les opérations d’administration de la
sécurité effectuées par l’administrateur sont couvertes par la politique
de contrôle d’accès aux opérations d’administration de la sécurité.
Argumentaire : FDP_ACC.2 soutient FMT_MOF.1 et FMT_MTD.1 pour satisfaire à l’objectif de
contrôle d’accès aux opérations d’administration spécifié par O.PCAOA, en garantissant que la
politique de contrôle d’accès aux opérations d’administration est appliquée à toutes les
opérations.
5.2.3.1.4 FMT_MOF.1 – Administration du comportement des fonctions de sécurité
[FMT_MOF.1.1] Les fonctions de contrôle d’accès aux opérations d’administration de
la sécurité doivent restreindre la capacité d’activer, de désactiver,
d’effectuer ou de modifier la programmation horaire des fonctions de
sécurité du tableau ci-dessous aux administrateurs, en fonction des
droits ci-dessous :
Fonctions de sécurité Opérations / droits nécessaires
Fonctions de filtrage  Modifier la programmation
horaire : F+M
Fonctions de chiffrement et d’établissement des SA  Activer / désactiver : V+M
Fonctions d’identification / authentification  Activer / désactiver : *+M
Fonctions de sauvegarde  Effectuer : *
Fonctions de restauration  Effectuer : ne peut être effectué
que par le super-administrateur
Argumentaire : FMT_MOF.1 est dédié à la satisfaction de l’objectif O.PCAOA. Ce composant
couvre les tâches d’administration consistant à déclencher des fonctions de sécurité.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 51 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
C I B L E D E S É C U R I T É
5.2.3.1.5 FMT_MTD.1 – Administration des données de sécurité
[FMT_MTD.1.1] Les fonctions de contrôle d’accès aux opérations d’administration de
la sécurité doivent restreindre la capacité de consulter, de modifier ou
d’effacer les données de sécurité du tableau ci-dessous aux
administrateurs, en fonction des droits ci-dessous :
Données de sécurité Opérations / droits nécessaires
Caractéristiques des utilisateurs  Consulter : tous les administrateurs
 Modifier : U+M
Attribution du rôle administrateur et de droits
administratifs à un utilisateur
 Consulter : tous les administrateurs
 Modifier : uniquement par le super-
administrateur.
Configuration des interfaces  Consulter : tous les administrateurs
 Modifier : *+M
Objets décrivant la topologie du réseau : machines,
réseaux, protocoles et services prédéfinis
 Consulter : tous les administrateurs
 Modifier : O+M
Slots de filtrage : contenu, programmation horaire  Consulter : F
 Modifier : F+M
Slots de chiffrement : contenu  Consulter : V
 Modifier : V+M
Fichiers de trace des événements de sécurité  Consulter (et auditer) : L
 Effacer : L+M
Paramètres de la journalisation et de la remontée
d'alarmes dont : profils des événements système et
réception des alarmes par mail
 Consulter : *
 Modifier : *+M
Paramètres de l'analyse dynamique, dont profils des
attaques Internet
 Consulter : *
 Modifier : *+M
Sauvegarde et restauration de configuration  Sauvegarde: *
 Restauration: uniquement par le
super-administrateur.
Base de temps  Consulter : tous les administrateurs
 Modifier : *+M
Argumentaire : FMT_MTD.1 est dédié à la satisfaction de l’objectif O.PCAOA. Ce composant
couvre les tâches d’administration consistant à modifier les données de sécurité.
5.2.3.2 Fonctions de sauvegarde et de restauration
5.2.3.2.1 FMT_MTD.BRS – Sauvegarde et restauration des données de sécurité
[FMT_MTD.BRS.1]
Les fonctions de sauvegarde / restauration doivent pouvoir sauvegarder
les données de sécurité sur le disque dur de la station d’administration.
[FMT_MTD.BRS.2]
Les fonctions de sauvegarde / restauration doivent permettre de
restaurer des données de sécurité sauvées sur le disque dur de la station
d’administration.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 52 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
C I B L E D E S É C U R I T É
Argumentaire : FMT_MTD.BRS est dédié à la satisfaction de l’objectif
O.SAUVEGARDE_RESTAURATION. Le recours à ce composant explicite a été nécessaire car
les composants de [CC-02] ne permettent pas de spécifier la sauvegarde ou la restauration de
données de sécurité.
5.2.3.3 Qualité de la documentation d’exploitation
5.2.3.3.1 ADO_IGS.1 – Procédures d’installation, de génération et de démarrage
Cf. [CC-03], § 8.2, p. 82-83.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif O.QUALITE_DOC.
5.2.3.3.2 AGD_ADM.1 – Guides de l’administrateur
Cf. [CC-03], § 10.1, p. 119-120.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif O.QUALITE_DOC.
5.2.3.3.3 AGD_USR.1 – Guide de l’utilisateur
Cf. [CC-03], § 10.2, p. 120-121.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif O.QUALITE_DOC.
5.2.3.3.4 AVA_MSU.1 – Examen des guides
Cf. [CC-03], § 13.2, p. 155-156.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif O.QUALITE_DOC. Il couvre
les aspects « contrôle sous l'angle des risques de mauvaise utilisation de la TOE ».
5.2.4 Exigences de protection de la TOE
5.2.4.1 Fonctions de protection des sessions d’administration
5.2.4.1.1 FPT_ITT.1 – Protection élémentaire du contenu des sessions d’administration
[FPT_ITT.1.1] Les fonctions de protection des sessions d’administration doivent
protéger le contenu des sessions d’administration contre la divulgation
et la modification quand elles sont transmises entre la station
d’administration et le boîtier appliance firewall-VPN.
Argumentaire : FPT_ITT.1 est dédié à la satisfaction de l’objectif
O.PROTECT_SESSIONS_ADMIN.
5.2.4.1.2 FTP_TRP.1.Admin – Chemin de confiance pour l’administration à distance
[FTP_TRP.1.Admin.1]
Les fonctions de protection des sessions d’administration doivent
fournir un chemin de communication entre les administrateurs et l’IPS-
Firewall qui soit logiquement distinct des autres chemins de communication
et qui garantisse l’identification de ses extrémités et la protection des
données transférées contre une modification ou une divulgation.
[FTP_TRP.1.Admin.2]
Les fonctions de protection des sessions d’administration doivent
permettre aux administrateurs d’initier une communication via le chemin de
confiance.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 53 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
[FTP_TRP.1.Admin.3]
Les fonctions de protection des sessions d’administration doivent
exiger l’utilisation du chemin de confiance pour :
l’authentification mutuelle initiale de l’administrateur et de l’IPS-
Firewall,
les opérations d’administration à distance de la sécurité.
Argumentaire : FTP_TRP.1.Admin est dédié à la satisfaction de l’objectif
O.PCAOA_I&A_ADMIN. Il soutient d’autre part FPT_ITT.1 pour satisfaire
O.PROTECT_SESSIONS_ADMIN en fournissant les moyens de protéger les sessions
d’administration.
5.2.4.1.3 FIA_UAU.5.Admin – Mécanisme d’authentification des administrateurs
[FIA_UAU.5.Admin.1]
Les fonctions de protection des sessions d’administration doivent
fournir le mécanisme basé sur le protocole SRP pour contribuer à
l’authentification de l’administrateur.
[FIA_UAU.5.Admin.2]
Les fonctions de protection des sessions d’administration doivent
authentifier l’identité annoncée de tout administrateur selon le protocole
SRP.
Argumentaire : FIA_UAU.5.Admin soutient FTP_TRP.1.Admin pour satisfaire l’objectif
O.PCAOA_I&A_ADMIN. La résistance des mécanismes associés au protocole SRP permet de
satisfaire l’objectif O.RESIST_AUTH_ADMIN : la protection contre le rejeu et la contrefaçon des
données d’authentification est garantie par l’utilisation d’un défi / réponse basé sur des clés
éphémères d’entropie supérieure à 2048 bits et générées d’une manière qui empêche les
attaques par référence sur les secrets d’authentification de référence (valeur v de vérification du
mot de passe, cf. [SRP]).
5.2.5 Autres exigences de sécurité de soutien
5.2.5.1 Autres fonctions de soutien
5.2.5.1.1 FCS_COP.1 – Fonctions cryptographiques
[FCS_COP.1.1] Les fonctions cryptographiques doivent effectuer les opérations
cryptographiques du tableau ci-dessous conformément aux algorithmes
cryptographiques spécifiés ci-dessous et avec les tailles des clés
cryptographiques spécifiées ci-dessous, en conformité avec les standards
énoncés ci-dessous.
Opération
cryptographique
Algorithme Taille des
clés
Réf. du standard Exigences soutenues
a. Signature et
élaboration
de clé
Diffie-Hellman 1536,
2048
[DH], [IKE], [IKE-
MODP], [SRP]
FIA_UAU.5.Utilisateur,
FIA_UAU.5.Admin,
FIA_UAU.5.Corresp.
b. Chiffrement /
déchiffrement
asymétrique
RSA 2048,
4096
[RSA] FIA_UAU.5.Corresp
(X509)
c. Hachage
univoque
HMAC-SHA1 160 [HMAC], [SHA1] FTP_TRP.1.Corresp,
FIA_UAU.5.Corresp,
FDP_UIT.1
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 54 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
C I B L E D E S É C U R I T É
Opération
cryptographique
Algorithme Taille des
clés
Réf. du standard Exigences soutenues
d. Chiffrement /
déchiffrement
symétrique
des paquets
VPN
AES 128, 192
ou 256
[AES] FDP_UCT.1
Triple DES 168 [DES]
Blowfish 128 à 256 [Blowfish]
CAST 128 [CAST]
FTP_TRP.1.Corresp,
FDP_UCT.1
e. Chiffrement /
déchiffrement
symétrique
des sessions
d’administra-
tion
AES 128 [AES]
f. Contrôle
d’intégrité
des sessions
d’administra-
tion.
HMAC-SHA1 160 [HMAC], [SHA1]
Argumentaire : FCS_COP.1 soutient toutes les exigences spécifiées dans la colonne de droite
pour la satisfaction de leurs objectifs de sécurité respectifs.
5.2.5.1.2 FPT_STM.1 – Base de temps fiable
[FPT_STM.1.1] La TSF doit être capable de fournir un horodatage fiable pour son propre
usage.
Argumentaire : ce composant soutient FAU_GEN.1 et FMT_MOF.SSB, pour la satisfaction des
objectifs O.JAA_PCFI, O.JAA_IPS, O.JAA_PCAOA et O.PCFI_HORAIRE.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 55 de 109 Référence : na_tn_ciblesec_fr.sxw
35
40
C I B L E D E S É C U R I T É
5.3 Exigences d’assurance sécurité pour la TOE
Cette section présente le raffinement des exigences d'assurance de la TOE. La description
formelle de ces exigences figure au chapitre 8. Pour assurer la traçabilité, on indique ici le titre
des exigences d'assurance concernées entre crochets (ex : [ADV_LLD.1.1D]).
5.3.1 Autres mesures d’assurance sécurité
5.3.1.1 ADV_FSP.1 – Spécifications fonctionnelles informelles
Cf. [CC-03], § 9.1, p. 90.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif
O.CONFORMITE_FONCTIONS.
5.3.1.2 ADV_HLD.2 – Conception de haut niveau - identification des sous-systèmes dédiés à
la sécurité
Cf. [CC-03], § 9.2, p. 95-96.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif
O.CONFORMITE_FONCTIONS.
5.3.1.3 ADV_LLD.1 – Conception de bas niveau descriptive des fonctions cryptographiques
Tâches du développeur :
[ADV_LLD.1.1D] Le développeur doit fournir la conception de bas niveau des fonctions
cryptographiques.
Contenu et présentation des éléments de preuve :
[ADV_LLD.1.1C] La présentation de la conception de bas niveau des fonctions
cryptographiques doit être en style informel.
[ADV_LLD.1.2C] La conception de bas niveau des fonctions cryptographiques doit avoir
une cohérence interne.
[ADV_LLD.1.3C] La conception de bas niveau des fonctions cryptographiques doit décrire
les fonctions cryptographiques en termes de modules cryptographiques.
[ADV_LLD.1.4C] La conception de bas niveau des fonctions cryptographiques doit décrire
le but de chaque module cryptographique.
[ADV_LLD.1.5C] La conception de bas niveau des fonctions cryptographiques doit définir
les relations mutuelles entre les modules cryptographiques en termes de
fonctionnalités de sécurité fournies et de dépendances vis-à-vis des autres
modules cryptographiques.
[ADV_LLD.1.6C] La conception de bas niveau des fonctions cryptographiques doit décrire
comment chaque fonction cryptographique est fournie.
[ADV_LLD.1.7C] La conception de bas niveau des fonctions cryptographiques doit identifier
toutes les interfaces des modules cryptographiques.
[ADV_LLD.1.8C] La conception de bas niveau des fonctions cryptographiques doit identifier
les interfaces des modules cryptographiques qui sont visibles de
l’extérieur.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 56 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
[ADV_LLD.1.9C] La conception de bas niveau des fonctions cryptographiques doit décrire
le but et le mode d’utilisation de toutes les interfaces des modules
cryptographiques, en fournissant, lorsque cela est approprié, les détails sur
les effets, les exceptions et les messages d’erreur.
[ADV_LLD.1.10C] La conception de bas niveau des fonctions cryptographiques doit décrire
la séparation de la TOE en modules cryptographiques et en autres
modules.
Tâches de l’évaluateur :
[ADV_LLD.1.1E] L’évaluateur doit confirmer que les informations fournies satisfont à toutes
les exigences relatives au contenu et à la présentation des éléments de
preuve.
[ADV_LLD.1.2E] L’évaluateur doit déterminer que la conception de bas niveau des fonctions
cryptographiques est une instantiation correcte et complète des exigences
fonctionnelles de sécurité de la classe FCS pour la TOE.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif
O.CONFORMITE_FONCTIONS.
5.3.1.4 ADV_IMP.1 – Implémentation des fonctions cryptographiques
Tâches du développeur :
[ADV_IMP.1.1D] Le développeur doit fournir la représentation de l’implémentation des
fonctions cryptographiques.
Contenu et présentation des éléments de preuve :
[ADV_IMP.1.1C] La représentation de l’implémentation des fonctions cryptographiques doit
définir les fonctions cryptographiques d’une façon non ambiguë avec un
niveau de détail suffisant pour qu’elle puisse être générée sans décision de
conception supplémentaire.
[ADV_IMP.1.2C] La représentation de l’implémentation des fonctions cryptographiques doit
avoir une cohérence interne.
Tâches de l’évaluateur :
[ADV_IMP.1.1E] L’évaluateur doit confirmer que les informations fournies satisfont à toutes
les exigences relatives au contenu et à la présentation des éléments de
preuve.
[ADV_IMP.1.2E] L’évaluateur doit déterminer que le plus bas niveau de représentation des
fonctions cryptographiques fourni est une instantiation correcte et
complète des exigences fonctionnelles de sécurité de la classe FCS pour la
TOE.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif
O.CONFORMITE_FONCTIONS.
5.3.1.5 ALC_TAT.1 – Outils de développement des fonctions cryptographiques bien définis
Tâches du développeur :
[ALC_TAT.1.1D] Le développeur doit identifier les outils de développement utilisés pour les
fonctions cryptographiques de la TOE.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 57 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
[ALC_TAT.1.2D] Le développeur doit documenter les options dépendant de l’implémentation
du compilateur qui ont été choisies pour les outils de développement des
fonctions cryptographiques.
Contenu et présentation des éléments de preuve :
[ALC_TAT.1.1C] Tous les outils de développement utilisés pour l’implémentation des
fonctions cryptographiques doivent être bien définis.
[ALC_TAT.1.2C] La documentation relative aux outils de développement des fonctions
cryptographiques doit définir sans ambiguïté la signification de toutes les
instructions utilisées dans l’implémentation des fonctions
cryptographiques.
[ALC_TAT.1.3C] La documentation relative aux outils de développement des fonctions
cryptographiques doit définir sans ambiguïté la signification de toutes les
options dépendant de l’implémentation du compilateur .
Tâches de l’évaluateur :
[ALC_TAT.1.1E] L’évaluateur doit confirmer que les informations fournies satisfont à toutes
les exigences relatives au contenu et à la présentation des éléments de
preuve.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif
O.CONFORMITE_FONCTIONS.
5.3.1.6 ADV_RCR.1 – Démonstration de correspondance informelle
Cf. [CC-03], § 9.6, p. 112-113.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif
O.CONFORMITE_FONCTIONS.
5.3.1.7 ATE_COV.1 – Éléments de preuve de la couverture
Cf. [CC-03], § 12.1, p. 135-136.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif
O.CONFORMITE_FONCTIONS.
5.3.1.8 ATE_FUN.1 – Tests fonctionnels
Cf. [CC-03], § 12.3, p. 143.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif
O.CONFORMITE_FONCTIONS.
5.3.1.9 ATE_IND.2 – Tests indépendants - échantillonnage
Cf. [CC-03], § 12.4, p. 147-148.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif
O.CONFORMITE_FONCTIONS.
5.3.1.10 ALC_FLR.3 – Correction d’anomalies systématique
Cf. [CC-03], § 11.2, p. 126-128.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif
O.CONFORMITE_FONCTIONS.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 58 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
5.3.1.11 AVA_SOF.1 – Évaluation de la résistance des fonctions de sécurité de la TOE
Cf. [CC-03], § 13.3, p. 159-160.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif
O.EFFICACITE_FONCTIONS.
5.3.1.12 AVA_VLA.2 – Analyse de vulnérabilités indépendante
Cf. [CC-03], § 13.4, p. 162-163.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif
O.EFFICACITE_FONCTIONS.
5.3.1.13 ACM_CAP.2 – Éléments de configuration
Cf. [CC-03], § 7.2, p. 70.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif O.INTEGRITE_TOE.
5.3.1.14 ADO_DEL.1 - Procédures de livraison
Cf. [CC-03], § 8.1, p. 80.
Argumentaire : ce composant est dédié à la satisfaction de l’objectif O.INTEGRITE_TOE.
5.3.1.15 ALC_DVS.1 – Identification des mesures de sécurité
Cf. [CC-03], § 11.1, p. 123.
Argumentaire : ce composant est dédié à la satisfaction des objectifs O.INTEGRITE_TOE et
O.CONFIDENTIALITE_TOE.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 59 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
C I B L E D E S É C U R I T É
5.4 Exigences de sécurité pour l’environnement TI
Aucune exigence de sécurité n’est spécifiée pour l’environnement TI.
5.5 Argumentaire des exigences de sécurité
5.5.1 Satisfaction des objectifs de sécurité
La satisfaction des objectifs de sécurité est exprimée dans les rubriques « argumentaires » qui
accompagnent l’énoncé de chaque exigence de sécurité. Le lien entre les exigences et les
objectifs de sécurité est résumé ci-dessous.
O.PCFI_FILTRAGE
O.PCFI_I&A_UTIL
O.PCFI_CONTEXTE_APPLICATIF
O.PCFI_CHIFFREMENT
O.JAA_PCFI
O.PCFI_HORAIRE
O.IPS_DETECTION_ATTAQUES
O.IPS_CONFORMITE_RFC
O.JAA_IPS
O.RESIST_AUTH_UTIL
O.PCAOA
O.PCAOA_I&A_ADMIN
O.JAA_PCAOA
O.SAUVEGARDE_RESTAURATION
O.QUALITE_DOC
O.RESIST_AUTH_ADMIN
O.PROTECT_JOURN
O.PROTECT_SESSIONS_ADMIN
O.CONFORMITE_FONCTIONS
O.EFFICACITE_FONCTIONS
O.INTEGRITE_TOE
O.CONFIDENTIALITE_TOE
FDP_IFC.2 S
FDP_IFF.1.Filtrage X X X
FIA_UID.2 X
FIA_UAU.2 X
FIA_UAU.5.Utilisateur S X
FDP_IFC.1 S
FDP_UCT.1 X
FDP_UIT.1 X
FDP_IFF.1.Chiffrement S
FTP_TRP.1.Corresp X
FIA_UAU.5.Corresp S
FPT_TDC.1 S
FAU_GEN.1 X X X
FAU_GEN.2 X
FAU_SAR.1 X X X
FAU_STG.3 X
FAU_ARP.1.Alarmes X X X
FMT_MOF.SSB X
FAU_SAA.4 X X
FAU_ARP.1.IPS S S X
FMT_SMF.1 S S S S
FMT_SMR.1 S
FDP_ACC.2 S
FMT_MOF.1 X
FMT_MTD.1 X
FMT_MTD.BRS X
ADO_IGS.1 X
AGD_ADM.1 X
AGD_USR.1 X
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 60 de 109 Référence : na_tn_ciblesec_fr.sxw
5
C I B L E D E S É C U R I T É
O.PCFI_FILTRAGE
O.PCFI_I&A_UTIL
O.PCFI_CONTEXTE_APPLICATIF
O.PCFI_CHIFFREMENT
O.JAA_PCFI
O.PCFI_HORAIRE
O.IPS_DETECTION_ATTAQUES
O.IPS_CONFORMITE_RFC
O.JAA_IPS
O.RESIST_AUTH_UTIL
O.PCAOA
O.PCAOA_I&A_ADMIN
O.JAA_PCAOA
O.SAUVEGARDE_RESTAURATION
O.QUALITE_DOC
O.RESIST_AUTH_ADMIN
O.PROTECT_JOURN
O.PROTECT_SESSIONS_ADMIN
O.CONFORMITE_FONCTIONS
O.EFFICACITE_FONCTIONS
O.INTEGRITE_TOE
O.CONFIDENTIALITE_TOE
AVA_MSU.1 X
FPT_ITT.1 X
FTP_TRP.1.Admin X S
FIA_UAU.5.Admin S X
FCS_COP.1 S S S S S
FPT_STM.1 S S S S
ADV_FSP.1 X
ADV_HLD.2 X
ADV_LLD.1 X
ADV_IMP.1 X
ALC_TAT.1 X
ADV_RCR.1 X
ATE_COV.1 X
ATE_FUN.1 X
ATE_IND.2 X
ALC_FLR.3 X
AVA_SOF.1 X
AVA_VLA.2 X
ACM_CAP.2 X
ADO_DEL.1 X
ALC_DVS.1 X X
5.5.2 Cohérence de la résistance des fonctions de sécurité avec les objectifs de sécurité
Le niveau de résistance minimum des fonctions annoncé (‘SOF-high’) est supérieur au niveau
maximum de moyens à la disposition des attaquants envisageable au cours de l’évaluation
(potentiel d’attaque ‘élémentaire’). Ce niveau est spécifié par le composant d’assurance sécurité
AVA_VLA.2 qui soutient, à travers l’objectif O.EFFICACITE_FONCTIONS, tous les objectifs
couverts par les fonctions de sécurité de la TOE. Il n’y a donc pas d’incohérence entre le niveau
de résistance minimum des fonctions annoncé et les objectifs de sécurité.
5.5.3 Soutien mutuel et non contradiction
Toutes les dépendances sont satisfaites ou bien leur non-satisfaction a été justifiée. Les
exigences de sécurité forment donc un ensemble qui se soutient mutuellement et ne présente
pas de contradiction.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 61 de 109 Référence : na_tn_ciblesec_fr.sxw
10
15
C I B L E D E S É C U R I T É
5.5.4 Satisfaction des dépendances
Le tableau ci-dessous résume les dépendances des composants d’exigences de sécurité et
justifie en quoi elles sont satisfaites ou bien pourquoi elles ne le sont pas.
Composant Dépendances Satisfaction
FDP_IFC.2 FDP_IFF.1 FDP_IFF.1.Filtrage
FDP_IFF.1.Filtrage FDP_IFC.1 FDP_IFC.2
FMT_MSA.3 Les attributs de sécurité des
paquets IP sont déduits du
contenu des en-têtes IP et
transport. Dans ces conditions,
la notion de « valeur restrictive
des attributs » n’est pas claire
et de toute manière ces
attributs ne sont pas sous le
contrôle de la TSF. La
dépendance n’est donc pas
applicable.
FIA_UID.2 Aucune
FIA_UAU.2 FIA_UID.1 FIA_UID.2
FIA_UAU.5.Utilisateur Aucune
FDP_IFC.1 FDP_IFF.1 FDP_IFF.1.Chiffrement
FDP_UCT.1 FTP_ITC.1 | FTP_TRP.1 FTP_TRP.1.Corresp
FDP_ACC.1 | FDP_IFC.1 FDP_IFC.1
FDP_UIT.1 FTP_ITC.1 | FTP_TRP.1 FTP_TRP.1.Corresp
FDP_ACC.1 | FDP_IFC.1 FDP_IFC.1
FDP_IFF.1.Chiffrement FDP_IFC.1 FDP_IFC.1
FMT_MSA.3 Les attributs de sécurité des
paquets IP sont déduits du
contenu des en-têtes IP et
transport. Dans ces conditions,
la notion de « valeur restrictive
des attributs » n’est pas claire
et de toute manière ces
attributs ne sont pas sous le
contrôle de la TSF. La
dépendance n’est donc pas
applicable.
FTP_TRP.1.Corresp Aucune
FIA_UAU.5.Corresp Aucune
FPT_TDC.1 Aucune
FAU_GEN.1 FPT_STM.1 Oui.
FAU_GEN.2 FAU_GEN.1
FIA_UID.1
Oui.
Satisfaite par FIA_UID.2
FAU_SAR.1 FAU_GEN.1 Oui.
FAU_STG.3 FAU_STG.1 Satisfaite par FMT_MTD.1
(fichiers de trace des
événements de sécurité)
FAU_ARP.1.Alarmes FAU_SAA.1 Non. Non applicable.
FMT_MOF.SSB FPT_STM.1 FPT_STM.1
FAU_SAA.4 Aucune
FAU_ARP.1.IPS FAU_SAA.1 FAU_SAA.4
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 62 de 109 Référence : na_tn_ciblesec_fr.sxw
C I B L E D E S É C U R I T É
Composant Dépendances Satisfaction
FMT_SMR.1 FIA_UID.1 Satisfaite par
FTP_TRP.1.Admin
FDP_ACC.2 FDP_ACF.1 Satisfaite par FMT_MOF.1 et
FMT_MTD.1
FMT_MOF.1 FMT_SMR.1
FMT_SMF.1
Oui
Oui
FMT_MTD.1 FMT_SMR.1
FMT_SMF.1
Oui
Oui
FMT_SMF.1 Aucune
FMT_MTD.BRS FMT_MTD.1
FMT_SMF.1
Oui
Oui
ADO_IGS.1 AGD_ADM.1 Oui
AGD_ADM.1 ADV_FSP.1 Oui
AGD_USR.1 ADV_FSP.1 Oui
AVA_MSU.1 ADO_IGS.1, ADV_FSP.1,
AGD_ADM.1, AGD_USR.1
Oui
FPT_ITT.1 Aucune
FTP_TRP.1.Admin Aucune
FIA_UAU.5.Admin Aucune
FCS_COP.1
a. Signature et élaboration
de clé
FDP_ITC.1 | FCS_CKM.1 Non applicable : l’opération est
une méthode de génération de
clé.
FCS_CKM.4 Non applicable : les clés ne
sont pas accessibles
physiquement ou logiquement
aux attaquants. Il n’est donc
pas nécessaire de les effacer
d’une manière particulière.
FMT_MSA.2 Satisfaite par FPT_TDC.1 pour
le groupe Diffie-Hellman, la
durée de vie, et l’algorithme.
Les autres attributs des clés
cités dans [CC-02], § 5.1,
p. 38, § 159 ne peuvent pas
être changés au cours de la
vie de la clé. La dépendance
n'est donc pas applicable pour
ces attributs.
FCS_COP.1
b. Chiffrement /
déchiffrement asymétrique
FDP_ITC.1 | FCS_CKM.1 Non applicable car en dehors
de la portée de la TOE. Les
certificats sont téléchargés sur
l’IPS-Firewall par
l’administrateur.
FCS_CKM.4 Non applicable car en dehors
de la portée de la TOE
FMT_MSA.2 Non applicable car les attributs
des clés (i.e. les champs du
certificats) ne peuvent être
changés.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 63 de 109 Référence : na_tn_ciblesec_fr.sxw
C I B L E D E S É C U R I T É
Composant Dépendances Satisfaction
FCS_COP.1
c. Hachage univoque
FDP_ITC.1 | FCS_CKM.1 Satisfaite par FCS_COP.1.a
FCS_CKM.4 Non applicable : les clés ne
sont pas accessibles
physiquement ou logiquement
aux attaquants. Il n’est donc
pas nécessaire de les effacer
d’une manière particulière.
FMT_MSA.2 Satisfaite par FPT_TDC.1 pour
la taille de la clé, la durée de
vie, et l’algorithme.
Les autres attributs des clés
cités dans [CC-02], § 5.1,
p. 38, § 159 ne peuvent pas
être changés au cours de la
vie de la clé. La dépendance
n'est donc pas applicable pour
ces attributs.
FCS_COP.1
d. Chiffrement /
déchiffrement symétrique
des paquets VPN
FDP_ITC.1 | FCS_CKM.1 Satisfaite par FCS_COP.1.a
FCS_CKM.4 Non applicable : les clés ne
sont pas accessibles
physiquement ou logiquement
aux attaquants. Il n’est donc
pas nécessaire de les effacer
d’une manière particulière.
FMT_MSA.2 Satisfaite par FPT_TDC.1 pour
la taille de la clé, la durée de
vie, et l’algorithme.
Les autres attributs des clés
cités dans [CC-02], § 5.1,
p. 38, § 159 ne peuvent pas
être changés au cours de la
vie de la clé. La dépendance
n'est donc pas applicable pour
ces attributs.
FCS_COP.1
e. Chiffrement /
déchiffrement symétrique
des sessions d’administra-
tion
FDP_ITC.1 | FCS_CKM.1 Satisfaite par FCS_COP.1.a
FCS_CKM.4 Non applicable : les clés ne
sont pas accessibles
physiquement ou logiquement
aux attaquants. Il n’est donc
pas nécessaire de les effacer
d’une manière particulière.
FMT_MSA.2 Non applicable car aucun des
attributs des clés cités dans
[CC-02], § 5.1, p. 38, § 159 ne
peut être changé au cours de
la vie de la clé.
FCS_COP.1
f. Contrôle d’intégrité des
sessions d’administration.
FDP_ITC.1 | FCS_CKM.1 Satisfaite par FCS_COP.1.a
FCS_CKM.4 Non. Non applicable.
FMT_MSA.2 Non applicable car aucun des
attributs des clés cités dans
[CC-02], § 5.1, p. 38, § 159 ne
peut être changé au cours de
la vie de la clé.
FPT_STM.1 Aucune
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 64 de 109 Référence : na_tn_ciblesec_fr.sxw
C I B L E D E S É C U R I T É
Composant Dépendances Satisfaction
ADV_FSP.1 ADV_RCR.1 Oui
ADV_HLD.2 ADV_FSP.1, ADV_RCR.1 Oui
ADV_LLD.1 ADV_HLD.2, ADV_RCR.1 Oui
ADV_IMP.1 ADV_LLD.1, ADV_RCR.1,
ALC_TAT.1
Oui
ALC_TAT.1 ADV_IMP.1 Oui
ADV_RCR.1 Aucune
ATE_COV.1 ADV_FSP.1, ATE_FUN.1 Oui
ATE_FUN.1 Aucune
ATE_IND.2 ADV_FSP.1, AGD_ADM.1,
AGD_USR.1, ATE_FUN.1
Oui
ALC_FLR.3 Aucune
AVA_SOF.1 ADV_FSP.1 Oui
ADV_HLD.1 ADV_HLD.2
AVA_VLA.2 ADV_FSP.1, ADV_HLD.2,
ADV_IMP.1, ADV_LLD.1,
AGD_ADM.1, AGD_USR.1
Oui
ACM_CAP.2 Aucune
ADO_DEL.1 Aucune
ALC_DVS.1 Aucune
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 65 de 109 Référence : na_tn_ciblesec_fr.sxw
C I B L E D E S É C U R I T É
6 SPÉCIFICATIONS ABRÉGÉES DE LA TOE
Le but de cette section est de fournir une définition de haut niveau des fonctions
Le but de cette section est de fournir une définition de haut niveau des fonctions
de sécurité des TI qui sont censées satisfaire aux exigences fonctionnelles de
de sécurité des TI qui sont censées satisfaire aux exigences fonctionnelles de
sécurité, et des mesures d’assurance sécurité prises pour satisfaire aux
sécurité, et des mesures d’assurance sécurité prises pour satisfaire aux
exigences d’assurance sécurité.
exigences d’assurance sécurité.
6.1 Fonctions de sécurité des TI
La présentation des fonctions de sécurité des TI reprend le plan suivi pour la description des
exigences fonctionnelles de sécurité de la TOE.
Le niveau de résistance des fonctions utilisant ces mécanismes est ‘SOF-High’.
6.1.1 Fonctions de filtrage
La technologie ASQ inclut un moteur de filtrage dynamique des paquets (stateful inspection)
avec optimisation des règles permettant l’application de la politique de filtrage de manière sûre
et rapide. La mise en œuvre des fonctions de filtrage est basée sur la confrontation des attributs
de chaque paquet IP reçu aux critères de chaque règle du slot de filtrage actif. Le filtrage porte
sur tous les paquets sans exception. Les critères des règles de filtrage sont :
L’interface de réception des paquets IP couverts par la règle ;
La ou les machines à l’origine des flux d’information couverts par la règle ;
Le ou les protocoles IP, les services TCP/UDP ou les types de messages ICMP des flux
d’information couverts par la règle ;
La ou les machines destinataires des flux d’information couverts par la règle ;
L’utilisateur ou le groupe d’utilisateurs autorisés par la règle.
Les attributs des paquets IP qui sont confrontés aux quatre premiers critères cités sont
évidemment extraits des en-têtes Ethernet, IP, ICMP, UDP ou TCP des trames. En ce qui
concerne l’utilisateur ou le groupe d’utilisateurs autorisés par la règle, à partir du moment où un
utilisateur s’est identifié et authentifié avec succès à partir d’une machine donnée, l’IPS-Firewall
note ce fait et attribue le nom de login de cet utilisateur à tous les paquets IP présentant
l’adresse de cette machine comme adresse IP source (cf. fonctions d’identification /
authentification, § 6.1.2infra). En conséquence, les règles qui spécifient l’authentification des
utilisateurs, même sans préciser de contraintes sur les utilisateurs autorisés, ne peuvent
s’appliquer qu’à des paquets IP émis d’une machine à partir de laquelle un utilisateur s’est
préalablement authentifié.
Chaque règle de filtrage peut spécifier une action de contrôle et une action de journalisation.
Ces dernières sont décrites au § 6.1.5infra. Il y a quatre valeurs possibles pour l’action de
contrôle :
‘passer’ : le paquet est accepté et n’est pas confronté aux règles suivantes ;
‘bloquer’ : le paquet est détruit silencieusement ;
‘réinitialiser’ : le paquet est détruit et un signal TCP RST (cas TCP) ou ICMP unreachable
(cas UDP) est envoyé à l’émetteur ;
‘aucune’ : le paquet est confronté aux règles suivantes (sert à spécifier une action de
journalisation uniquement).
Si aucune règle de filtrage n’est applicable au paquet, ou si les seules qui le sont ne spécifient
‘aucune’ action de contrôle, le paquet est détruit silencieusement.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 66 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
Il convient de noter qu’à proprement parler, pour un ensemble de paquets IP liés à un même
échange au niveau transport (connexion TCP, pseudo-connexion UDP ou ICMP), l’IPS-Firewall
ne confronte que le paquet initial de l’échange aux règles du slot de filtrage courant. À la
réception de tout paquet IP, préalablement à l’application des règles du slot de filtrage courant,
le paquet est comparé aux connexions / pseudo-connexions actuellement établies. Si les
attributs et les paramètres du paquet correspondent aux critères et à l’état d’une de ces
connexions / pseudo-connexions, il est autorisé à passer sans être soumis aux règles de
filtrage. Ce mécanisme permet notamment de gérer les échanges bidirectionnels (notamment
les connexions TCP) sans avoir à définir une règle de filtrage dans les deux sens de traversée
du firewall.
Des règles de filtrage implicites sont générées par le firewall en liaison avec la configuration
d’autres fonctions de sécurité. Ce sont les règles correspondant à : l’administration à distance
du firewall, l’authentification des utilisateurs et l’établissement des VPN. Par ailleurs, des règles
de filtrage dynamiques sont également générées pour les protocoles nécessitant des
connexions filles.
À tout instant du fonctionnement du boîtier appliance firewall-VPN, il y a un slot de filtrage actif.
Argumentaire : les fonctions de filtrage satisfont FDP_IFC.2 et FDP_IFF.1.Filtrage.
6.1.2 Fonctions d’identification / authentification
Les fonctions d’identification / authentification permettent à l’utilisateur de déclarer son login
(identification) et de vérifier que cet utilisateur est bien la personne qu’il prétend être, par la
fourniture d’éléments qu’il est censé être le seul à pouvoir fournir (authentification). Une fois
l’authentification réussie, le login de l’utilisateur est attribué, à travers la table des utilisateurs
authentifiés, à la machine à partir de laquelle celui-ci s’est identifié et à tous les paquets IP qui
en proviennent (cf. § 6.1.1supra), et ce pour une durée spécifiée par l’utilisateur. L’utilisateur
peut également se retirer manuellement de la table des utilisateurs authentifiés avant cette
échéance.
Le mode d’utilisation soumis à l’évaluation impose le recours au protocole SRP pour
l’authentification des utilisateurs. Ce protocole sans divulgation de mot de passe est résistant
aussi bien aux attaques d’écoute passive qu’aux attaques actives basées sur la modification ou
l’insertion de paquets dans la séquence d’authentification. Il utilise un mot de passe réutilisable
fourni par l’utilisateur, et conserve ses propriétés de résistance aux attaques même lorsque
l’entropie du mot de passe est basse. Il fait l’objet de la RFC 2945 [SRP].
Concrètement, l’IPS-Firewall fournit, à travers des capacités de type ‘serveur HTTP’, des
formulaires Web qui permettent de s’identifier, de s’authentifier en spécifiant la durée de la
session, et de fermer la session manuellement. Il n’est pas nécessaire que la session HTTP
persiste pour que la session reste active. Les étapes du protocole SRP sont effectuées par une
applet Java téléchargée depuis l’IPS-Firewall sur le poste de l’utilisateur. Cette applet se sert du
mot de passe fourni par l’utilisateur pour mener les étapes du protocole SRP.
Le protocole SRP est décrit plus en détail au § 6.1.10.2infra (remplacer ‘administrateur’ par
‘utilisateur’ et ‘outil’ par ‘applet’). À la différence des fonctions de protection des sessions
d’administration, l’utilisation du protocole SRP pour authentifier les utilisateurs ne sert pas à
élaborer une clé de session dans le cadre d’un chemin de confiance.
Argumentaire : les fonctions d’identification / authentification satisfont FIA_UID.2 et FIA_UAU.2.
L’utilisation du protocole SRP satisfait FIA_UAU.5.Utilisateur.
L’utilisation de l’algorithme Diffie-Hellman dans le cadre du protocole SRP satisfait
FCS_COP.1.1.a concernant la partie de cette exigence qui soutient FIA_UAU.5.Utilisateur.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 67 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
45
C I B L E D E S É C U R I T É
6.1.3 Fonctions de chiffrement
Les fonctions de chiffrement de l’IPS-firewall implémentent le protocole ESP d’IPSec [IPSec,
ESP] pour fournir des services d’authentification et de chiffrement des datagrammes échangés
avec un correspondant VPN (éventuellement un autre IPS-firewall), possédant des
fonctionnalités homologues.
L'algorithme d’authentification supporté par l’IPS-Firewall est le HMAC-SHA1 (160 bits).
Les algorithmes de chiffrement supportés par l’IPS-Firewall sont : AES (128, 192 ou 256 bits),
Triple-DES (168 bits), Blowfish (128 à 256 bits) et CAST (128 bits).
L’IPS-firewall met en œuvre le protocole ESP en mode tunnel. Cela implique que les fonctions
de chiffrement peuvent ne pas être mises en œuvre sur le flux de bout en bout, mais
uniquement sur une portion du réseau qui supporte le flux, physiquement délimitée par les
correspondants VPN, typiquement le réseau non maîtrisé. Sur cette portion, les datagrammes
IP à protéger sont intégralement chiffrés, signés et encapsulés dans des datagrammes ESP
dont les adresses IP source et destination sont celles des correspondants VPN. Ainsi, les
adresses IP des machines réelles d’extrémité du flux sont inaccessibles à des attaquants à
l’écoute sur le réseau non maîtrisé. Les correspondants VPN sont appelés extrémités du tunnel,
par opposition aux machines réelles d’extrémité du flux, situées « derrière » les correspondants
VPN du point de vue du réseau non maîtrisé, et qu’on appelle les extrémités du trafic.
Figure 6-6.1. Protocole ESP en mode tunnel.
Dans le cadre d’ESP, chaque datagramme échangé entre deux correspondants VPN donnés
est rattaché à une connexion unidirectionnelle mettant en œuvre des services de sécurité,
appelée Association de Sécurité (Security Association ou SA). Chaque datagramme ESP
possède un index de sécurité (Security Policy Identifier ou SPI) qui identifie la SA IPSec à
laquelle il est rattaché.
Une SA IPSec spécifie les algorithmes de chiffrement et d’authentification à appliquer sur les
datagrammes qu’elle couvre, ainsi que les clés secrètes associées. Du point de vue d’un
correspondant VPN, une SA IPSec peut être entrante ou sortante.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 68 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
C I B L E D E S É C U R I T É
Index de sécurité (SPI)
Numéro de séquence
Code d’authentification du message
Données utiles
En-tête ESP
Authentification
Chiffrement
ESP Auth
Prochain en-tête
Lg. de bourrage
Bourrage
Datagramme IP encapsulé
Pied ESP
En-tête IP
(corresp. VPN)
Figure 6-6.2. Contenu d'un datagramme ESP.
Pour un échange bidirectionnel donné (par ex : une connexion TCP), les correspondants VPN
établissent une paire de SA IPSec (une pour chaque direction), chaque SA IPSec étant sortante
pour un correspondant et entrante pour l’autre. L’établissement des paires de SA IPSec fait
l’objet d’un ensemble fonctionnel de sécurité spécifique (cf. § 6.1.4infra).
Une SA IPSec possède une durée de vie au-delà de laquelle elle expire et doit être re-négociée.
Le correspondant VPN peut également provoquer la re-négociation de la SA IPSec en
application d’autres critères (ex : volume de données échangées).
À un moment donné, l’IPS-Firewall peut gérer une multitude de paires de SA IPSec. Il est
relativement facile de trouver la SA IPSec entrante associée à un datagramme ESP entrant
(grâce à l’index de sécurité), mais pour chaque datagramme IP sortant, la sélection de la SA
IPSec sortante nécessite la confrontation des attributs du datagramme aux critères de chaque
règle du slot de chiffrement actif. Les critères des règles de chiffrement5
sont :
La ou les machines à l’origine des flux d’information couverts par la règle ;
Le ou les protocoles IP ;
La ou les machines destinataires des flux d’information couverts par la règle.
À la différence des fonctions de chiffrement, si le datagramme IP sortant ne correspond à
aucune règle, il continue son chemin dans la pile. Il est alors soumis en clair aux fonctions de
filtrage. Autre différence : à un moment donné, il peut n’y avoir aucun slot de chiffrement actif.
Chaque règle de chiffrement est normalement associée à une paire de SA IPSec. Si le
datagramme IP sortant correspond à une règle de chiffrement possédant une SA IPSec sortante
valide, les traitements de cette SA IPSec sont appliqués au datagramme. Sinon, la SA IPSec
sortante est négociée (ou re-négociée). Si la négociation échoue, le paquet est détruit.
L’authenticité des datagrammes ESP entrants est contrôlée, puis ils sont déchiffrés. Une fois
désencapsulés, on contrôle également que les attributs du paquet IP obtenu sont bien
conformes aux critères de la règle de chiffrement associée à la SA IPSec.
Il convient de noter que l’on a parlé de « datagrammes » IP ou ESP dans toute cette section. En
effet, en cas de fragmentation, les paquets IP sortants ou ESP entrants sont ré-assemblés
avant l’application des fonctions de chiffrement.
5
On peut dire que les règles de chiffrement correspondent aux Security Policy Database entries de la RFC 2401 [IPSec], à ceci près que la SPD,
telle qu’elle est définie dans la RFC, couvre en toute rigueur les règles de chiffrement et de filtrage.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 69 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
C I B L E D E S É C U R I T É
Note d’application : les algorithmes DES (56 bits) et HMAC-MD5 (128 bits) sont également
supporté mais il est exclu du mode d’utilisation soumis à l’évaluation. De même, les algorithmes
CAST et Blowfish peuvent être paramétrés avec des tailles de clés inférieures à 128 bits, mais
cela sort du mode d’utilisation soumis à l’évaluation.
Argumentaire : les fonctions de chiffrement satisfont FDP_IFC.1, FDP_UCT.1, FDP_UIT.1 et
FDP_IFF.1.Chiffrement.
L’utilisation de l'algorithme HMAC-SHA1 pour les services de confidentialité de la SA IPSec
satisfait la partie de FCS_COP.1.1.c qui soutient FDP_UIT.1.
L’utilisation des algorithmes AES, Triple DES, Blowfish et CAST pour les services de
confidentialité de la SA IPSec satisfait la partie de FCS_COP.1.1.d qui soutient FDP_UCT.1.
6.1.4 Fonctions d’établissement des SA
6.1.4.1 IKE phase 2 : établissement de SA IPSec
L’établissement d’une SA IPSec entre deux correspondants VPN nécessite une phase de
négociation des paramètres et d’établissement des clés afin d’assurer que les deux extrémités
du tunnel appliquent la règle de chiffrement associée à la SA IPSec de manière cohérente. La
négociation des SA IPSec est basée sur la phase 2 (‘Quick Mode’) du protocole IKE [IKE]. De
manière simplifiée, les messages de cette négociation peuvent être représentées par le
diagramme de séquence ci-dessous :
Figure 6-6.3. Diagramme de séquence – négociation de SA IPSec.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 70 de 109 Référence : na_tn_ciblesec_fr.sxw
Initiateur :
correspondant VPN
Répondeur :
correspondant VPN
Proposition(propositions de SA IPSec,
aléa initiateur,
clé publique DH initiateur)
Réponse(proposition de SA IPSec choisie,
aléa répondeur,
clé publique DH répondeur)
Acquittement
5
10
15
C I B L E D E S É C U R I T É
Tous ces échanges sont chiffrés et authentifiés par les services fournis par une SA spéciale, la
SA ISAKMP, négociée et établie entre les correspondants VPN préalablement à l’établissement
des SA associées aux règles de chiffrement, appelées SA IPSec par opposition. On regroupe
dans la notion de tunnel l’ensemble des règles de chiffrement qui concernent un correspondant
VPN donné, auquel on associe la SA ISAKMP6
établie avec ce correspondant VPN.
Figure 6-6.4. Diagramme de classes –fonctions de chiffrement et de négociation des SA.
Chaque règle de chiffrement possède une liste de propositions de SA IPSec qui sont des
quintuplets de la forme (durée de vie de la SA, algorithme d’authentification, taille de clé
d’authentification, algorithme de chiffrement, taille de clé de chiffrement). En tant qu’initiateur,
l’IPS-Firewall propose cette liste.
L'algorithme d’authentification négociable est le HMAC-SHA1 (160 bits). L'algorithme de secret
partagé négociable est Diffie-Hellman (1536 bits). Les algorithmes de chiffrement négociables
sont l’AES (128, 192 ou 256 bits), le Triple DES (168 bits), Blowfish (128 à 256 bits) et CAST
(128 bits).
Lors du deuxième message de la phase 2 du protocole IKE, le répondeur doit choisir et recopier
dans sa réponse une des propositions qui lui a été soumise. En tant que répondeur, l’IPS-
Firewall sélectionne une réponse au moins aussi stricte que ses propositions locales.
Suite à la réussite de la négociation, les clés d’authentification et de chiffrement sont élaborées
à partir d'une dérivation des secrets d'authentification, du secret partagé Diffie-Hellman, des
aléas et des autres paramètres préalablement négociés.
Note d’application : d’autres stratégies peuvent être paramétrées par l’administrateur, mais elles
sont exclues du mode d’utilisation soumis à l’évaluation.
6
À la différence des SA IPSec, les SA ISAKMP sont bidirectionnelles.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 71 de 109 Référence : na_tn_ciblesec_fr.sxw
Correspondant VPN
Interface
Stratégie de négociation
Mécanisme d’authentification
mutuelle
Identité à déclarer (certificat/fqdn)
Tunnel
Durée de vie de la SA
Algorithme d’authentification et taille de la clé
Algorithme de chiffrement et taille de la clé
Proposition de SA
Durée de vie négociée
Âge actuel
Algorithme d’authentification négocié
Clé d’authentification établie
Algorithme de chiffrement négocié
Clé de chiffrement établie
SA ISAKMP
1
0..1
Machines locales couvertes
Machines distantes couvertes
Type de protocole couvert
Règle de chiffrement
1 1
0..* 0..*
0..1
0..1
1
1
0..*
Proposition
de SA
ISAKMP
Proposition
de SA
IPSec
SA entrante
SA sortante
Slot de
chiffrement
1
0..*
SA IPSec
Index de sécurité
Durée de vie négociée
Âge actuel
Algorithme d’authentification négocié
Clé d’authentification établie
Algorithme de chiffrement négocié
Clé de chiffrement établie
5
10
15
20
C I B L E D E S É C U R I T É
Argumentaire : les messages de proposition-réponse satisfont à FPT_TDC.1 concernant les SA
IPSec. La SA ISAKMP constitue un chemin de confiance (cf. § 6.1.4.2infra) dont l’utilisation, à
travers la phase 2 d’IKE, pour la négociation des SA IPsec satisfait FTP_TRP.1.Corresp.3.b.
L’utilisation de l’algorithme Diffie-Hellman satisfait FCS_COP.1.1.a concernant la partie de cette
exigence qui soutient FIA_UAU.5.Corresp.
L'algorithme HMAC-SHA1 est utilisé, conformément à la RFC 2409, pour générer les clés
secrètes de la SA IPSec et les codes d’authentification, ce qui satisfait la partie de
FCS_COP.1.1.c qui soutient FTP_TRP.1.Corresp. Cet algorithme est également utilisé pour les
services d’intégrité de la SA ISAKMP (cf. § 6.1.4.2infra), ce qui satisfait la partie de
FCS_COP.1.1.c qui soutient FTP_TRP.1.Corresp.1.
Les algorithmes Triple DES, Blowfish et CAST sont utilisés pour les services de confidentialité
de la SA ISAKMP (cf. § 6.1.4.2infra), ce qui satisfait la partie de FCS_COP.1.1.d qui soutient
FTP_TRP.1.Corresp.1.
6.1.4.2 IKE phase 1 : établissement de SA ISAKMP et authentification mutuelle
La phase 1 du protocole IKE, défini par la RFC 2408 [IKE], concourt à trois objectifs :
 La négociation des paramètres de la SA ISAKMP ;
 L’élaboration des clés secrètes d’authentification, de chiffrement et de dérivation de la SA
ISAKMP ;
 L’authentification mutuelle des correspondants VPN.
Une SA ISAKMP a une utilisation élargie au sens où elle peut-être utilisée pour sécuriser
plusieurs négociations de SA IPSec différentes.
Les fonctions d’établissement de SA n’acceptent des négociations de SA ISAKMP qu’avec des
correspondants VPN pour lesquels un tunnel est défini dans le slot de chiffrement courant, et ce
sur l’interface réseau spécifiée pour ce tunnel.
Le diagramme de séquence ci-dessous représente les passes de cette négociation en mode
principal (Main mode), utilisant une clé pré-partagée (pre-shared key) :
Figure 6-6.5. Diagramme de séquence – établissement de SA ISKAMP et
authentification mutuelle des correspondants VPN.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 72 de 109 Référence : na_tn_ciblesec_fr.sxw
Initiateur :
correspondant VPN
Répondeur :
correspondant VPN
Proposition(propositions de SA ISAKMP)
Réponse(proposition de SA ISAKMP choisie)
Échange(clé publique DH initiateur,
aléa initiateur)
Échange(clé publique DH répondeur,
aléa répondeur)
Authentification(identifiant initiateur,
code d’authentification initiateur)
Authentification(identifiant répondeur,
code d’authentification répondeur)
Passe
1
Passe
2
Passe
3
5
10
15
20
25
C I B L E D E S É C U R I T É
Le mode principal se compose de six messages qui représentent trois passes distinctes:
 La passe 1 correspond à la négociation de la SA ISAKMP.
Les principes appliqués par l’IPS-Firewall, en tant que répondeur, pour choisir une
proposition, sont les mêmes que pour la négociation des SA IPSec. L'algorithme
d’authentification négociable est HMAC-SHA1 (160 bits). Les algorithmes de chiffrement
négociables sont le Triple DES (168 bits), Blowfish (128 à 256 bits) et CAST (128 bits).
 La passe 2 permet l'échange de valeurs publiques Diffie-Hellman.
En vue d’élaborer, à partir des clés publiques Diffie-Hellman, un secret partagé dont on
dérive la clé secrète d’authentification et la clé secrète de chiffrement de la SA ISAKMP,
utilisables par les services négociés en passe 1. Une clé secrète de dérivation utilisée en
phase 2 IKE est également générée.
 La passe 3 permet l’authentification mutuelle des correspondants VPN.
Celle-ci est protégée par les services d’authentification et de chiffrement négociés en passe
1 et 2. Le code d’authentification de chaque correspondant VPN est généré à partir de la clé
pré-partagée, du secret partagé, des aléas et de l’identifiant du correspondant VPN.
D’autres modes de négociation et méthodes d’authentification sont supportés par l’IPS-Firewall :
Mode principal / mode agressif : en mode agressif, l’échange s’effectue en seulement trois
messages et non plus six comme en mode principal :
 Le 1er message combine la proposition, l’échange de clé initiateur et l’envoi de
l’identifiant de l’initiateur,
 Le 2ème message combine la réponse, l’échange de clé répondeur et
l’authentification du répondeur,
 Le 3ème message consiste pour l’initiateur à envoyer son code d’authentification ;
Clé pré-partagées / certificats X509 : en utilisant des certificats X509 en mode principal,
l’identifiant de chaque correspondant VPN est communiqué lors de la passe 2. Que ce soit
en mode principal ou en mode agressif, chaque correspondant VPN chiffre son identifiant
avec la clé publique de son vis-à-vis (algorithme RSA). Le code d’authentification de chaque
correspondant VPN est généré à partir du secret partagé, des aléas et de l’identifiant du
correspondant. Cela n’inclut donc pas l’équivalent de la clé pré-partagée mais, de même
que l’identifiant, les aléas sont chiffrés avec la clé publique du vis-à-vis à l’occasion de la
passe d’échange de clé, ce qui permet l’authentification de celui-ci.
Le tableau ci-dessous précise la nature de l’identifiant et les protections appliquées à l’identité,
en fonction du mode et de la méthode d’authentification :
Méthode
Mode
clé pré-partagée certificat X509
Principal Identifiant : adresse IP
Protection de l'identité : chiffrement
de la SA ISAKMP.
Identifiant : certificat X509
Protection de l'identité : clé publique du
vis-à-vis.
Agressif Identifiant : adresse IP, adresse de
mail ou nom de domaine
Protection de l'identité : non.
Identifiant : certificat X509
Protection de l'identité : clé publique du
vis-à-vis.
Note d’application : les algorithmes RSA et Diffie-Hellman avec des clés strictement inférieures
à 1536 bits sont également supportés mais exclus du mode d’utilisation soumis à l’évaluation.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 73 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
Argumentaire : le chemin de confiance spécifié par le composant FTP_TRP.1.Corresp est
implémenté par la phase 1 d’IKE, ce qui satisfait l’élément FTP_TRP.1.Corresp.2.
L’authentification mutuelle, qui garantit l’identification des extrémités (élément
FTP_TRP.1.Corresp.1), est établie à la fin de la dernière passe de chaque mode. Les services
assurant la confidentialité et l’intégrité (élément FTP_TRP.1.Corresp.1) sont effectifs à partir du
cinquième message en mode principal et du troisième en mode agressif. L’utilisation du chemin
de confiance pour l’authentification mutuelle initiale des correspondants VPN satisfait
FTP_TRP.1.Corresp.3.a.
Les deux mécanismes d’authentification sont ceux spécifiés par FIA_UAU.5.Corresp.
Les messages de proposition-réponse satisfont à FPT_TDC.1 concernant les SA ISAKMP.
L’utilisation de l’algorithme Diffie-Hellman satisfait FCS_COP.1.1.a concernant la partie de cette
exigence qui soutient FIA_UAU.5.Corresp.
En mode X509, l’utilisation de l’algorithme RSA satisfait FCS_COP.1.1.b.
L'algorithme HMAC-SHA1 est utilisé, conformément à la RFC 2409, pour générer les clés
secrètes et les codes d’authentification, ce qui satisfait la partie de FCS_COP.1.1.c qui soutient
FIA_UAU.5.Corresp. Cet algorithme est également utilisé pour les services d’intégrité de la SA
ISAKMP, ce qui satisfait la partie de FCS_COP.1.1.c qui soutient FTP_TRP.1.Corresp.1.
Les algorithmes Triple DES, Blowfish et CAST sont utilisés pour les services de confidentialité
de la SA ISAKMP, ce qui satisfait la partie de FCS_COP.1.1.d qui soutient
FTP_TRP.1.Corresp.1.
6.1.5 Fonctions de journalisation, d’audit et d’alarme
6.1.5.1 Fonctions de journalisation
L’IPS-Firewall gère un certain nombre de fichiers de trace destinés à recueillir les événements
détectés par les fonctions de journalisation. Les fichiers concernés par les événements de
sécurité sont :
Filtres : événements liés à l’application des fonctions de filtrage ;
VPN : événements liés à l’établissement des SA ;
Alarmes : événements liés à l’application des fonctions de prévention des intrusions ;
Authentification : événements liés à l’authentification des utilisateurs ;
Histo Manager : événements liés à l’authentification des administrateurs et aux opérations
d’administration de la sécurité ;
Système : arrêt/démarrage des fonctions de journalisation. Plus généralement : c’est dans
ce journal que sont enregistrés les événements liés directement au système :
arrêt/démarrage de l’IPS-Firewall, erreur système, etc. L’arrêt et démarrage des fonctions
de journalisation correspondent à l’arrêt et au démarrage des « démons » qui génèrent les
traces.
Les fichiers Filtres, VPN, Alarmes et Système partagent un espace global de stockage avec
d’autres fichiers de traces. L’administrateur possédant les droits ‘*+M’ peut spécifier le
pourcentage maximum que chacun des fichiers de trace peut occuper dans cet espace total.
Lorsque le seuil maximum est atteint, l’IPS-Firewall entreprend une action paramétrée, pour
chaque fichier, parmi les trois suivantes :
Rotation des fichiers : les traces les plus récentes effacent les traces les plus anciennes,
Stopper l'écriture des fichiers : les traces ne sont plus mémorisées sur le Firewall,
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 74 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
Arrêter le Firewall : le Firewall ne s'arrête pas réellement mais il bloque l'ensemble des flux
excepté les connexions du Firewall Manager depuis le réseau interne.
Les fichiers Authentification et Histo Manager ont chacun un espace alloué fixe et sont protégés
par des actions de rotation en cas de saturation.
Argumentaire : les fonctions de journalisation satisfont FAU_GEN.1 et FAU_GEN.2. La
justification détaillée de la satisfaction de chaque exigence sur les informations d’audit
enregistrées dans chaque type enregistrement sera apportée lors de l’évaluation. La limitation
de la taille des fichiers Filtres, VPN, Alarmes et Système, et les actions associées, satisfont à
l’exigence FAU_STG.3 pour ces fichiers. Pour Authentification et Histo Manager, l’exigence est
satisfaite a fortiori.
6.1.5.2 Fonctions d’audit
Les fonctions d’audit du Firewall Reporter permettent à l’auditeur d’afficher les événements
stockés dans chacun des fichiers de trace en effectuant :
Des sélections selon des périodes prédéfinies par rapport à la date courante (‘aujourd’hui’,
‘cette semaine’, etc.) ou définies manuellement ;
Des tris (croissants/décroissants) sur la valeur de chacun des champs des événements de
sécurité enregistrés ;
Des regroupements hiérarchiques en fonction de la valeur d’un ou plusieurs champs des
événements de sécurité enregistrés.
Le Firewall Monitor permet également de visualiser les événements les plus récents.
Argumentaire : les fonctions d’audit satisfont FMT_SMF.1.c, FAU_SAR.1.
6.1.5.3 Fonctions d’alarme
Les fonctions d’alarme permettent, suite à l’enregistrement d’un événement de sécurité
possédant un niveau d’alarme, d’effectuer les actions suivantes :
Allumer le voyant correspondant au niveau de l’alarme sur la face avant du boîtier appliance
firewall-VPN ;
Afficher l’alarme sur le Firewall Monitor ;
Envoyer l’alarme par e-mail aux utilisateurs spécifiés.
Argumentaire : les fonctions d’alarme satisfont FAU_ARP.1.Alarmes.
6.1.6 Fonctions de programmation horaire
Les slots de filtrage sont soumis à une programmation horaire. Pour chaque type de slot,
l’administrateur possédant les droits ‘F+M’ utilise une grille horaire qui est construite comme un
tableau interactif ; l’échelle horizontale représente les heures de la journée, et l’échelle verticale
les jours de la semaine. En sélectionnant un des slots préalablement définis et en balayant avec
la souris la surface correspondant à des plages horaires, on affecte ce slot à ces plages
horaires.
Il doit toujours y avoir un slot de filtrage actif à un moment donné. Lorsque l’administrateur part
d’une grille horaire de filtrage vierge pour définir ou modifier la programmation horaire du
filtrage, le premier slot de filtrage que l’administrateur sélectionne est automatiquement affecté à
toutes les heures de tous les jours de la semaine.
Argumentaire : les fonctions de programmation horaire satisfont FMT_MOF.SSB.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 75 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
6.1.7 Fonctions de prévention des intrusions
La technologie ASQ inclut un système de prévention des intrusions (intrusion prevention system
ou IPS) permettant la détection des attaques :
sans contexte, c’est-à-dire n’utilisant qu’un paquet IP ;
avec contexte de connexion, c’est-à-dire impliquant d’analyser plusieurs paquets associés à
une même connexion TCP / pseudo-connexion UDP ou ICMP ;
ou avec contexte global, c’est à dire nécessitant de recouper les contextes de plusieurs
connexions TCP / pseudo-connexions UDP ou ICMP.
Une technologie à base de plugins permet d’effectuer des contrôles au niveau applicatif dans le
but de mettre en œuvre la conformité aux RFC, le respect des bonnes pratiques et la prévention
contre des attaques connues sur les serveurs applicatifs.
Le détail des attaques potentielles détectées est fourni à l’annexe A, § 7. Pour chacune de ces
attaques, l’administrateur possédant les droits ‘*+M’ peut définir si les paquets incriminés
doivent être transmis ou détruits et s’il y a lieu de générer un événement de sécurité possédant
un niveau d’alarme, automatiquement enregistré dans le fichier de trace ‘Alarmes’.
Argumentaire : le système de prévention des intrusions satisfait aux exigences de FAU_SAA.4.
L’annexe A, § 7 rattache chaque attaque potentielle aux six types énoncés dans FAU_SAA.4.1.
L’indication d’une attaque potentielle (FAU_SAA.4.3) peut se traduire par une action sur le
paquet incriminé (ce qui satisfait FAU_ARP.IPS.1.a) et/ou la génération d’une alarme (ce qui
satisfait FAU_ARP.IPS.1.b).
6.1.8 Fonctions de contrôle d’accès aux opérations d’administration de la sécurité
Afin d'autoriser l'accès de l’IPS-Firewall à différentes personnes, le super-administrateur peut
affecter des droits de modification ou de consultation de la configuration aux utilisateurs définis
dans la base locale, ce qui en fait alors des administrateurs.
Parmi les différents droits existants qui peuvent être affectés aux utilisateurs, ceux concernant
les fonctions de sécurité définies dans la présente cible de sécurité, ainsi que leurs données de
sécurité associées, sont les suivants :
U = USER : droit de consultation des informations sur les utilisateurs,
O = OBJECT : droit de consultation des objets,
V = VPN : droit de consultation des configurations VPN,
F = FILTER : droit de consultation des règles de filtrage,
L = LOG : droit de consultation des traces,
* = OTHER : droit de consultation de tout ce qui n’est pas couvert par un autre droit :
interfaces, configuration de l’ASQ, taille maximum des fichiers de trace, etc.
Un droit supplémentaire peut être attribué : M = MODIFY : droit de modification. Ce droit
complète tous les autres droits attribués à un administrateur pour lui permettre la consultation et
la modification des données de sécurité.
Enfin, un droit particulier B = BASE tient lieu de rôle administrateur explicite. Un utilisateur qui ne
possède pas le droit ‘B’ n’est pas considéré comme un administrateur et ne peut pas ouvrir de
session d’administration.
Pour chaque opération élémentaire d’administration de la sécurité, les droits nécessaires sont
définis de manière détaillée (les détails seront fournis lors de l’examen de la conception de haut
niveau). Toutes les opérations d’administration de la sécurité effectuées par les administrateurs
sont donc couvertes par la politique de contrôle d’accès que ces droits implémentent.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 76 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
Le compte dont le login est ‘admin’ est toujours défini par défaut et n’est pas géré dans la base
locale. On l’appelle le « super-administrateur ». Il possède tous les droits plus un droit spécial
A = ADMIN, et il est le seul à pouvoir effectuer certaines opérations (créer un utilisateur et lui
attribuer des droits administratifs, effectuer une restauration de la configuration, etc.)
Note d’application : Rappel : dans le mode d’utilisation qui fait l’objet de l’évaluation, le super-
administrateur n’est pas censé se connecter sur l’IPS-Firewall lors des phases d’exploitation
hormis la promotion d'un utilisateur en administrateur.
Argumentaire : le système de droits décrit ci-dessus satisfait aux exigences de FMT_SMF.1.a,
FMT_MTD.1 et FMT_MOF.1. Le fait que toutes les opérations d’administration de la sécurité
soient soumises aux contrôle d’accès satisfait FDP_ACC.2. La définition donnée ci-dessus des
administrateurs et du super-administrateur satisfait FMT_SMR.1.1. L’association du compte
‘admin’ au super-administrateur satisfait FMT_SMR.1.2.a. La nécessité d’attribuer le droit ‘B’
explicitement aux administrateurs satisfait FMT_SMR.1.2.b.
6.1.9 Fonctions de sauvegarde et de restauration
L’administrateur possédant le droit ‘*’ peut sauvegarder dans un fichier sur la station
d’administration :
La configuration complète ;
La configuration réseau de l’IPS-Firewall (adresses du Firewall, routeurs,...) ;
Les objets (machines, réseaux, services et chacun des groupes) ;
Les règles de filtrage ;
La base LDAP (base locale des utilisateurs).
La restauration de la configuration à partir d’un fichier de sauvegarde est du ressort exclusif du
super-administrateur.
Argumentaire : les fonctions de sauvegarde et de restauration satisfont FMT_SMF.1.d et
FMT_MTD.BRS.
6.1.10 Fonctions de protection des sessions d’administration
6.1.10.1 Chiffrement et authentification des sessions d’administration
Les sessions établies entre les outils de la suite d’administration NETASQ (Firewall Manager,
Firewall Monitor, Firewall Reporter) et l’IPS-Firewall sont chiffrées avec l’algorithme AES 128
bits. Leur contenu est donc protégé en confidentialité.
L’intégrité du contenu des sessions d’administration est contrôlé à l’aide de l’algorithe HMAC-
SHA1, avec une longueur de clés de 160 bits.
Les clés d’authentification et de chiffrement des sessions d’administration à distance sont
dérivées de la clé de session établie suite à l’authentification SRP de l’administrateur.
Argumentaire : le chiffrement en AES 128 bits des sessions d’administration satisfait FPT_ITT.1
et FCS_COP.1.1.e. Le contrôlé d’intégrité par HMAC-SHA1 160 bits satisfait FPT_ITT.1 et
FCS_COP.1.1.f. La nécessité pour l’administrateur de s’authentifier via le protocole SRP pour
pouvoir dériver la clé de chiffrement de l’AES 128 bits de la clé de session SRP satisfait
FMT_SMF.1.b, FTP_TRP.1.Admin.3.b.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 77 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
6.1.10.2 Authentification des administrateurs et élaboration de la clé de chiffrement par le
protocole SRP
Outil IPS-Firewall
Login
Graine
Échange(clé publique DHéphémère outil)
Échange([clé publique DHéphémère IPS-FW
+ valeur de vérification]
,
aléa public)
Authentification(code d
’authentification administrateur)
Authentification(code d’authentification IPS
-FW)
Passe
1
Passe
2
Passe
3
Administrateur
Login, mot de passe
•Calcule clé privée DH administrateur
(mot de passe, graine)
•Génère clé privée DHéphémère outil
•Retrouvegraine et valeur de
vérification àpartir du login
•Calcule secret partag
é
{formule client}
•Calcule clé de session
(secret partag
é)
•Calcule code d’authentification
administrateur
 Login
 Graine
 Valeur de
vérification
Profil
administrateur
•Génère cléprivée DH éphémère
IPS-FW
•Calcule secret partag
é
{formule serveur}
•Calcule cléde session
(secret partag
é)
•Calcule code d’authentification
IPS-FW
•Génère aléapublic
Figure 6-6.6. Diagramme de séquence – protocole SRP (simplifié).
Le protocole SRP permet à un « client » (dans notre cas : les outils d’administration comme le
Firewall Manager) et à un « serveur » (l’IPS-Firewall) de s’authentifier mutuellement et de
négocier une clé de session servant à protéger les échanges ultérieurs.
Lors de la création du profil de chaque administrateur, l’IPS-Firewall génère une graine qui
permet combinée au mot de passe de dériver une clé privée DH administrateur dont la clé
publique DH correspondante est appelée valeur de vérification. La graine et la valeur de
vérification sont stockées dans le profil de l’administrateur, la clé privée DH administrateur n’est
pas conservée par l’IPS-Firewall. Notez que même si la valeur de vérification est une « clé
publique » au sens Diffie-Hellman du terme, il est nécessaire que l’IPS-Firewall la protége
contre la divulgation, de plus celle-ci n'est jamais transmise à un tiers.
Lors de la passe 1, l’outil soumet le login de l’administrateur et l’IPS-Firewall lui renvoie la
graine. L’outil recalcule la clé privée DH administrateur, sans la divulguer.
Lors de la passe 2, l’outil et l’IPS-Firewall génèrent des clés privées DH éphémères puis
s’échangent les clés publiques DH éphémères correspondantes, ainsi qu’un aléa public généré
par l’IPS-Firewall. Les participants calculent alors un secret partagé à l’aide de deux formules
mathématiques différentes – mais qui aboutissent au même résultat – utilisant les paramètres
suivants :
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 78 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
C I B L E D E S É C U R I T É
Paramètres de la formule client Paramètres de la formule serveur
 [clé publique DH éphémère IPS-FW +
valeur de vérification],
 clé privée DH administrateur,
 clé privée DH éphémère outil,
 aléa public
 clé privée DH éphémère IPS-FW,
 valeur de vérification,
 clé publique DH éphémère outil,
 aléa public
Une clé de session est dérivée du secret partagé.
La passe 3 est une preuve mutuelle de possession du secret partagé, les codes
d’authentification étant générés à partir de la clé de session et des clés publiques DH
éphémères.
Note d’application : de plus amples détails sont fournis dans la RFC 2945 [SRP] et dans
[Wu98].
Argumentaire : le chemin de confiance entre l'administrateur et l'IPS-Firewall spécifié par
FTP_TRP.1.Admin est implémenté par le protocole SRP, tel que spécifié par FIA_UAU.5.Admin.
Dans ce protocole, l’initiative de l’authentification revient à l’administrateur, ce qui satisfait
FTP_TRP.1.Admin.2. L’authentification mutuelle, qui garantit l’identification des extrémités
(élément FTP_TRP.1.Admin.1), est établie à la fin de la dernière passe du protocole. L’utilisation
du chemin de confiance pour l’authentification mutuelle initiale de l'administrateur et de l'IPS-
Firewall satisfait FTP_TRP.1.Admin.3.a et FMT_SMF.1.b
L’utilisation de l’algorithme Diffie-Hellman satisfait FCS_COP.1.1.a concernant la partie de cette
exigence qui soutient FIA_UAU.5.Admin.
6.1.11 Autres fonctions de soutien
Les fonctions cryptographiques sont présentées avec les sous-ensembles fonctionnels de
sécurité qu’elles soutiennent, ainsi que la justification des différentes exigences élémentaires
spécifiées par FCS_COP.1.
L’horloge interne du boîtier appliance firewall-VPN fournit une base de temps fiable
(FPT_STM.1).
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 79 de 109 Référence : na_tn_ciblesec_fr.sxw
25
30
35
40
C I B L E D E S É C U R I T É
6.2 Mesures d’assurance sécurité
6.2.1 Mesures de l’environnement de développement
6.2.1.1 Méthodes et outils de gestion de configuration
Le système de gestion de configuration couvre la gestion et le contrôle du développement, de la
production et de la maintenance de la suite logicielle IPS-Firewall. Son application permet
d’affecter un identifiant unique à chaque version de la TOE et d’établir une liste des versions des
composants qui constituent une version donnée.
Le commanditaire documente les procédures du système de gestion de configuration et fournit
une liste de configuration pour chaque version de la TOE présentée.
L’évaluateur évalue la documentation et contrôle, sur les versions de la TOE qui lui sont livrées
par le commanditaire, que le système de gestion de configuration est bien appliqué tel que
décrit dans la documentation (pas d’audit de l’environnement de développement sous ce
critère).
Références des fournitures : na_pr_gesconf_fr
Argumentaire : ces procédures satisfont à l’exigence ACM_CAP.2.
6.2.1.2 Sécurité de l’environnement de développement
Les mesures de sécurité appliquées pour le développement et la maintenance de la suite
logicielle IPS-Firewall garantissent l’intégrité du code exécutable de la TOE et la confidentialité
des documents de développement associés.
Le commanditaire documente les mesures de sécurité de l’environnement de développement en
identifiant précisément le périmètre cet environnement, et fournit des traces de l’application de
ces mesures.
L’évaluateur évalue la documentation et procède à un audit de l’environnement afin de vérifier et
d’apprécier l’application des mesures, et d’interviewer les personnels concernés sur leur
connaissance des mesures.
Références des fournitures : na_pr_secphy_fr, na_pr_seclog_fr et na_pr_secint_fr
Argumentaire : ces procédures satisfont à l’exigence ALC_DVS.1.
6.2.1.3 Procédures de livraison
Les procédures et mesures mises en place pour transférer la suite logicielle IPS-Firewall du
développeur chez l’utilisateur final garantissent l’authenticité et l’intégrité de la TOE lors du
transfert.
Le commanditaire documente les procédures de livraison.
L’évaluateur évalue la documentation et procède à un audit de l’environnement afin de vérifier et
d’apprécier l’application des mesures, et d’interviewer les personnels concernés sur leur
connaissance des mesures.
Références des fournitures : na_pr_livraison_fr
Argumentaire : ces procédures satisfont à l’exigence ADO_DEL.1.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 80 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
6.2.1.4 Procédures de correction des anomalies
Des procédures de correction des anomalies sont mises en place au niveau du laboratoire et du
service support pour assurer une gestion et un contrôle des anomalies de sécurité découvertes
en interne ou soumises par les exploitants, ainsi que la distribution des correctifs associés, une
fois les anomalies résolues.
Le commanditaire documente les procédures visant à la correction des anomalies, et fournit les
documents donnant des lignes directrices aux exploitants pour lui soumettre les anomalies.
L’évaluateur évalue la documentation (pas d’audit de l’environnement de développement sous
ce critère).
Références des fournitures : na_pr_getvul_fr, na_pr_qualif_fr et na_pr_pubvul_fr
Argumentaire : ces procédures satisfont à l’exigence ALC_FLR.3.
6.2.2 Documentation et outils de développement des fonctions de sécurité
Le commanditaire fournit les documents permettant d’assurer un niveau de qualité compatible
avec les exigences liées au paquet d’assurance sécurité : spécifications fonctionnelles,
conception de haut niveau et, uniquement pour les fonctions cryptographiques, conception de
bas niveau, documentation des outils et techniques de développement (compilateurs, makefiles,
…) et code source. Ces documents forment les niveaux successifs de représentation de la
fonctionnalité de sécurité.
Des correspondances entre ces niveaux sont établies, en commençant par les fonctions de
sécurité des TI spécifiées de manière abrégée dans ce document (§ 6.1supra).
L’évaluateur évalue la documentation, et vérifie que les exigences fonctionnelles de sécurité du
§ 5.2 se reflètent bien dans les différents niveaux de représentation de la fonctionnalité de
sécurité.
Références des fournitures :
na_tn_specfonc_fr, na_hld_archi_50, na_hld_auth_50, na_hld_asq_50, na_hld_ipsec_50,
na_hld_isakmp_50, na_hld_log_50, na_hld_alarmd_50, na_hld_serverd_50, na_hld_ldap_50,
na_hld_hardwared_50, na_hld_eventd_50, na_hld_ihm_50 et na_lld_crypto_50
Argumentaire : ces mesures satisfont aux exigences ADV_FSP.1, ADV_HLD.2, ADV_LLD.1,
ALC_TAT.1, ADV_IMP.1 et ADV_RCR.1.
6.2.3 Test des fonctions de sécurité
6.2.3.1 Procédures de test du développeur
Le commanditaire fournit les documents produits à l’occasion des tests qu’il a effectués sur la
TOE. Ces documents doivent décrire le plan et les procédures de tests suivies et montrer le
degré de couverture des spécifications fonctionnelles par les tests. Ils doivent inclure les
résultats effectifs des tests et démontrer que les fonctions de sécurité se comportent bien de la
manière spécifiée dans les spécifications fonctionnelles.
Le commanditaire met également à disposition de l’évaluateur une TOE se prêtant au
repassage des tests qu’il a effectués sur la TOE.
L’évaluateur évalue la documentation et repasse une partie des tests du développeur.
Références des fournitures :
na_qa_plan_50, na_qa_asqfil_50, na_qa_asqips_50, na_qa_auth_50, na_qa_vpn_50,
na_qa_audit_50, na_qa_eventd_50, na_qa_admin_50, na_qa_test_50 et na_pr_qualif_fr
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 81 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
Argumentaire : ces procédures satisfont aux exigences ATE_FUN.1, ATE_COV.1 et à une
partie d’ATE_IND.2 (repassage des tests).
6.2.3.2 Test indépendant par l’évaluateur
Le commanditaire met à disposition de l’évaluateur une TOE se prêtant à l’exécution de tests
indépendants.
Sur la base des spécifications fonctionnelles et de la documentation de test, l’évaluateur conçoit
des tests complémentaires des fonctions de sécurité, afin de valider des comportements de
sécurité de la TOE que le commanditaire n’aurait pas testés.
Références des fournitures : sans objet.
Argumentaire : ces mesures satisfont à une partie de l’exigence ATE_IND.2 (test indépendant).
6.2.4 Documentation d’exploitation
6.2.4.1 Procédures d’installation et de démarrage
Ces procédures permettent l’installation et le démarrage de la TOE dans des conditions qui
garantissent une exécution satisfaisante de ses fonctions de sécurité.
Afin de prévenir les risques d’utilisation impropre, la documentation d’installation et de
démarrage doit spécifiquement identifier tous les modes d’exécution possibles de la TOE ainsi
que leur impact sur la sécurité. Elle doit être claire, complète, cohérente, et accessible à
l’audience visée. Elle doit enfin énumérer toutes les hypothèses relatives à l’environnement
d’exploitation prévu et les exigences sur les mesures de sécurité (TI ou non-TI) qui doivent être
présentes dans l’environnement.
Le commanditaire documente les procédures d’installation et de démarrage sûrs de la TOE.
L’évaluateur évalue la documentation, au besoin en ré-appliquant les procédures ou une partie
d’entre elles.
Références des fournitures : na_qs_asv5 et na_ug_asv5_fr
Argumentaire : ces procédures satisfont aux exigences ADO_IGS.1 et AVA_MSU.1 (concernant
la documentation d’installation et de démarrage).
6.2.4.2 Documentation d’administration
La documentation d’exploitation à destination des administrateurs doit décrire le comportement
des fonctions de sécurité et refléter les hypothèses sur l’environnement d’exploitation, dans une
optique de configuration, de maintenance et de maintien en condition opérationnelle corrects
des fonctions de sécurité. Elle doit également décrire les différents types d’événements relatifs à
la sécurité susceptibles de survenir, et fournir des lignes directrices sur la manière de les
prendre en compte.
Des exigences spécifiques à la prévention de l’utilisation impropre, similaires à celles sur la
documentation d’installation et de démarrage, pèsent également sur la documentation
d’administration
Le commanditaire fournit la documentation d’administration.
L’évaluateur évalue la documentation d’administration.
Références des fournitures : na_ug_asv5_fr
Argumentaire : ces mesures satisfont aux exigences AGD_ADM.1 et AVA_MSU.1 (concernant
la documentation d’administration).
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 82 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
40
C I B L E D E S É C U R I T É
6.2.4.3 Documentation utilisateur
La documentation d’exploitation à destination des utilisateurs doit décrire le comportement des
fonctions de sécurité qu’ils ont besoin de connaître, et refléter les hypothèses sur
l’environnement d’exploitation et les responsabilités qui les concernent (et notamment les
situations qui nécessitent d’en référer à l’administrateur).
Des exigences spécifiques à la prévention de l’utilisation impropre, similaires à celles sur la
documentation d’installation et de démarrage et d’administration, peuvent également peser sur
la documentation utilisateur, sous réserve de leur pertinence et de leur applicabilité aux
utilisateurs.
Le commanditaire fournit la documentation utilisateur.
L’évaluateur évalue la documentation utilisateur.
Références des fournitures : na_ug_asv5_fr
Argumentaire : ces mesures satisfont aux exigences AGD_USR.1 et AVA_MSU.1 (concernant
la documentation utilisateur).
6.2.5 Estimation de la vulnérabilité
Cette tâche s’appuie sur les résultats de toutes les tâches précédentes et sur des sources
publiques pour identifier les faits techniques (vulnérabilités) susceptibles de causer la réalisation
de menaces identifiées dans la présente cible de sécurité ou des infractions aux règles de
politiques de sécurité organisationnelles de la présente cible de sécurité. La résistance des
mécanismes de sécurité de nature combinatoire ou probabiliste aux attaques directes est
également estimée.
Le commanditaire doit fournir une analyse de vulnérabilités énonçant toutes les vulnérabilités
qu’il a décelées au cours du développement, montrant qu’elles ne sont pas exploitables et
justifiant que la cible d’évaluation résiste aux attaques de pénétration requérant une
compréhension minimale de son fonctionnement.
Une analyse de la résistance des mécanismes pour lesquels une annonce de résistance des
fonctions a été faite dans la présente cible de sécurité doit également être fournie par le
commanditaire.
L’évaluateur rédige une analyse indépendante de vulnérabilités (à destination exclusive de
l’organisme de certification), sur la base des autres fournitures de l’évaluation, afin de confirmer
ou d’infirmer les résultats des analyses du commanditaire. Il procède d’autre part à des tests de
pénétration dans le but d’estimer les moyens nécessaires à la mise en œuvre des vulnérabilités
(compétence technique, temps, expertise, etc.). Cette tâche permet de confirmer ou d’infirmer
que le niveau minimum de moyens nécessaires estimés, mesurés selon une métrique décrite
dans les Critères Communs [CEM-02, annexe B.8], est strictement supérieur à ceux
correspondant à un potentiel d’attaque élémentaire.
Références des fournitures : na_tn_vuln_fr et na_tn_resit_fr
Argumentaire : ces mesures satisfont aux exigences AVA_SOF.1 et AVA_VLA.2.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 83 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
35
C I B L E D E S É C U R I T É
6.3 Argumentaire des spécifications abrégées de la TOE
La satisfaction des exigences de sécurité est exprimée dans les rubriques « argumentaires » qui
accompagnent l’énoncé de chaque mesure de sécurité. Le lien entre les mesures et les
exigences de sécurité est résumé ci-dessous.
6.3.1 Satisfaction des exigences fonctionnelles de sécurité
FDP_IFC.2
FDP_IFF.1.Filtrage
FIA_UID.2
FIA_UAU.2
FIA_UAU.5.Utilisateur
FDP_IFC.1
FDP_UCT.1
FDP_UIT.1
FDP_IFF.1.Chiffrement
FTP_TRP.1.Corresp
FIA_UAU.5.Corresp
FPT_TDC.1
FAU_GEN.1
FAU_GEN.2
FAU_SAR.1
FAU_STG.3
FAU_ARP.1.Alarmes
FMT_MOF.SSB
FAU_SAA.4
FAU_ARP.1.IPS
FMT_SMF.1
FMT_SMR.1
FDP_ACC.2
FMT_MOF.1
FMT_MTD.1
FMT_MTD.BRS
FPT_ITT.1
FTP_TRP.1.Admin
FIA_UAU.5.Admin
FCS_COP.1
FPT_STM.1
Fonctions de
filtrage
X X
Fonctions
d'identification/
authentification
X X X a
Fonctions de
chiffrement
X X X X c
d
Établissement
des
SA
IKE phase
2: établist.
de SA
IPSec
X X a
c
d
IKE phase
1: établist.
De SA
ISAKMP et
authent.
mutuelle
X X X a
b
c
d
Fonctions de
journalisation
X X X
Fonctions
d'audit
X X
Fonctions
d'alarme
X
Fonctions de
programmation
horaire
X
Fonctions de
prévention des
intrusions
X X
Fonctions de
contrôle
d'accès aux
opé. d'admin.
de la séc.
X X X X X
Fonctions de
sauvegarde et
de restauration
X X
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 84 de 109 Référence : na_tn_ciblesec_fr.sxw
5
C I B L E D E S É C U R I T É
FDP_IFC.2
FDP_IFF.1.Filtrage
FIA_UID.2
FIA_UAU.2
FIA_UAU.5.Utilisateur
FDP_IFC.1
FDP_UCT.1
FDP_UIT.1
FDP_IFF.1.Chiffrement
FTP_TRP.1.Corresp
FIA_UAU.5.Corresp
FPT_TDC.1
FAU_GEN.1
FAU_GEN.2
FAU_SAR.1
FAU_STG.3
FAU_ARP.1.Alarmes
FMT_MOF.SSB
FAU_SAA.4
FAU_ARP.1.IPS
FMT_SMF.1
FMT_SMR.1
FDP_ACC.2
FMT_MOF.1
FMT_MTD.1
FMT_MTD.BRS
FPT_ITT.1
FTP_TRP.1.Admin
FIA_UAU.5.Admin
FCS_COP.1
FPT_STM.1
Protect.
des
sessions
d'admin.
Chiffremen
t et
authentific
ation des
sessions
d'admin.
X X X ef
Authent.
des admin.
et élabn.
de la clé
de chifft.
X X X a
Horloge interne X
6.3.2 Satisfaction des exigences d’assurance sécurité
ACM_CAP.2
ADO_DEL.1
ADO_IGS.1
ADV_FSP.1
ADV_HLD.2
ADV_IMP.1
ADV_LLD.1
ADV_RCR.1
AGD_ADM.1
AGD_USR.1
ALC_DVS.1
ALC_FLR.3
ALC_TAT.1
ATE_COV.1
ATE_FUN.1
ATE_IND.2
AVA_MSU.1
AVA_SOF.1
AVA_VLA.2
Méthodes et outils de gestion de
configuration
X
Sécurité de l’environnement de
développement
X
Procédures de livraison X
Procédures de correction des
anomalies
X
Documentation et outils de
développement des fonctions de
sécurité
X X X X X X
Procédures de test du
développeur
X X X
Test indépendant par l’évaluateur X
Procédures d’installation et de
démarrage
X X
Documentation d’administration X X
Documentation utilisateur X X
Estimation de la vulnérabilité X X
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 85 de 109 Référence : na_tn_ciblesec_fr.sxw
C I B L E D E S É C U R I T É
7 ANNEXE A – ATTAQUES PRISES EN COMPTE PAR LE MOTEUR
DE FILTRAGE ASQ
Cette section a pour objet l’énumération complète des attaques prises en compte
Cette section a pour objet l’énumération complète des attaques prises en compte
par le moteur de filtrage ASQ et leur rattachement aux catégories d’attaques
par le moteur de filtrage ASQ et leur rattachement aux catégories d’attaques
définies par l’exigence élémentaire FAU_SAA.4.1.
définies par l’exigence élémentaire FAU_SAA.4.1.
Catégorie Attaque Type d’attaque
(au sens de
FAU_SAA.4.1)
IP Usurpation d'adresse de boucle (IP loopback address spoofing) a
Usurpation d'adresse IP (IP address spoofing) a
Paquet Broadcast (Broadcast Packet) b
Paquet Multicast (Multicast Packet) b
Adresse de classe expérimentale (Address from experimental
class)
b
Mauvaise option IP (Bad IP option) b
Option IP inconnue (Unknown IP option) b
Protocole IP non analysé (Unanalyzed IP protocol) b
Machine du réseau interne inconnue (Unknown internal network
host)
b
Débordement de fragment (Oversized fragment) b
Recouvrement de fragment (Overlapped fragment) b
Routage par la source (Source routing) b
Fragment IP de taille nulle (Zero sized fragment received) b
Port 0 utilisé comme service (Port 0 used as service) b
Petit fragment (Tiny fragment) b
Utilisation de l'adresse privée d'une interface (Direct access to
private interface)
b
Usurpation d'adresse IP sur un bridge (IP address spoofing on
bridge)
a
Protocole IP invalide (Invalid IP protocol) b
Utilisation de l'adresse broadcast en source (Broadcast address
used in source address)
b
Usurpation d'adresse IP sur l'interface IPSec(IP address spoofing
on IPSec interface)
a
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 86 de 109 Référence : na_tn_ciblesec_fr.sxw
5
C I B L E D E S É C U R I T É
Catégorie Attaque Type d’attaque
(au sens de
FAU_SAA.4.1)
TCP Attaque possible par MSS faible (Possible small MSS attack) b
Attaque Xmas tree (Xmas tree attack) b
Adresse Multicast avec TCP (Multicast address with TCP) b
Somme de contrôle TCP invalide (Wrong TCP checksum) b
Mauvais numéro de séquence TCP (Wrong TCP sequence
number)
b
Option TCP inconnue (Unknown TCP option) b
Option TCP invalide (Invalid TCP option) b
Option TCP au mauvais moment (Misplaced TCP option) b
Évasion de données sur TCP (TCP data evasion) b
Adresse Broadcast avec TCP (Broadcast address with TCP) b
Paquet TCP invalide par rapport à l'état (Invalid TCP packet for
current connection state)
b
Protocole TCP invalide (Invalid TCP protocol) b
UDP Bouclage de port UDP (UDP port loopback) b
Somme de contrôle UDP invalide (Wrong UDP checksum) b
Protocole UDP invalide (Invalid UDP protocol) b
IGMP Type IGMP inconnu (Unknown IGMP type) b
Demande IGMP pour une adresse non Multicast (Non-multicast
address in IGMP query)
b
Paquet IGMP invalide (Invalid IGMP packet) b
Somme de contrôle IGMP invalide (Wrong IGMP checksum) b
ICMP Type ICMP inconnu (Unknown ICMP type) b
Réponse ICMP sans requête (ICMP reply without request) b
ICMP redirect (ICMP redirect) b
Message ICMP invalide (Invalid ICMP message) b
Demande ICMP timestamp (ICMP timestamp request) b
Demande ICMP mask (ICMP mask request) b
Demande ICMP information (ICMP Information request) b
Attaque possible par MTU faible (Possible small MTU attack) b
Somme de contrôle ICMP invalide (Wrong ICMP checksum) b
DoS Attaque de type LAND (Land style attack) b
Possible saturation ICMP (Possible ICMP flooding) f
Possible saturation UDP (Possible UDP flooding) f
Possible saturation TCP SYN (Possible TCP SYN flooding) f
Bug Windows sur les données OOB (Windows OOB data bug) d
Scan Sonde OS nmap (Nmap OS probe) e
Sonde OS queso (Queso OS probe) e
Sonde OS xprobe (Xprobe OS probe) e
Détection de la politique de filtrage (Firewall policy detection) e
Possible scan de ports (Possible port scan) e
Misc Paquet RIP invalide (Invalid RIP packet) b
Sonde de port (Port Probe) e
Protocole eDonkey invalide (Invalid eDonkey protocol) c
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 87 de 109 Référence : na_tn_ciblesec_fr.sxw
C I B L E D E S É C U R I T É
Catégorie Attaque Type d’attaque
(au sens de
FAU_SAA.4.1)
DNS Récursion de label DNS (DNS label recursion) d
DNS id spoofing (DNS id spoofing) c
DNS zone change (DNS zone change) c
DNS zone update (DNS zone update) c
Empoisonnement du cache DNS (DNS cache poisoning) c
Protocole DNS invalide (bad DNS protocol) c
FTP Attaque FTP bounce possible (Possible FTP bounce attack) d
Tentative d'insertion de commande FTP PASV (FTP PASV
insertion attack)
c
Commande FTP inconnue (Unknown FTP command) c
Débordement en FTP sur les commandes USER/PASSWORD
(Buffer onverflow on FTP USER/PASSWORD)
d
Débordement en FTP sur une commande (Buffer overflow on FTP
command)
d
Attaque en force brute sur mot de passe FTP (Brute force attack
on FTP password)
c
Exécution de commande via SITE EXEC (Command execution
using SITE EXEC)
c
FTP PASV DoS (FTP PASV DoS) c
Protocole FTP invalide (Invalid FTP protocol) c
HTTP Encodage en caractère %u invalide dans l'URL (Invalid %u
encoding char in URL)
c
Évasion utilisant l'encodage %u dans l'URL (Evasion using %u
encoding char in URL)
d
Caractère d'échappement invalide dans l'URL (Invalid escaped
char in URL)
c
Caractère NULL codé dans l'URL (Escaped NULL char in URL) d
Caractère Pourcent codé dans l'URL (Escaped percent char in
URL)
d
Évasion utilisant l'encodage UTF-8 (Evasion using UTF-8
encoding)
d
Protocole HTTP invalide (Invalid HTTP protocol) c
Débordement dans une URL (Possible buffer overflow on URL) d
Débordement dans le protocole HTTP (Possible buffer overflow on
HTTP request)
d
Tunneling possible avec la méthode CONNECT (Tunneling using
CONNECT method)
c
Suite de slash dans l'URL (Multiple slashes in URL) d
Chemin avec auto-référence (Directory self-reference) c
Chemin avec référence supérieure (Directory traversal) c
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 88 de 109 Référence : na_tn_ciblesec_fr.sxw
C I B L E D E S É C U R I T É
8 ANNEXE B – IDENTIFICATION DES OPÉRATIONS EFFECTUÉES
SUR LES EXIGENCES DE SÉCURITÉ DES TI
Cette section a pour objet l’identification précise des opérations effectuées sur les
Cette section a pour objet l’identification précise des opérations effectuées sur les
exigences de sécurité des TI, requise par l’exigence ASE_REQ.1.6C. Elle doit être
exigences de sécurité des TI, requise par l’exigence ASE_REQ.1.6C. Elle doit être
considérée comme «
considérée comme « l’énoncé des exigences de sécurité des TO fourni en tant que
l’énoncé des exigences de sécurité des TO fourni en tant que
partie de la ST
partie de la ST », requis par l’exigence ASE_REQ.1.1D,
», requis par l’exigence ASE_REQ.1.1D,
8.1 Introduction
En plus des quatre types d’opérations définies dans les Critères Communs (cf. [CC-01],
§ 4.4.1.3.2, p. 36), deux types supplémentaires de modification du texte original des exigences
de sécurité des TI ont été introduites :
Le raffinement systématique : il s’agit d’un raffinement effectué de manière homogène sur
tous les éléments d’un composant ;
La mise en forme : il s’agit d’une transformation de la structure grammaticale d’un élément,
de manière à le rendre plus facile à lire, ou à supprimer du texte inutile, mais qui ne change
absolument pas le sens de l’élément. Cela correspond à la notion d’editorial refinement
détaillée dans [CEM-02], § 218.c, p. 42.
Les opérations ont été effectuées sur le texte anglais original des exigences de sécurité des TI,
mais elles ont pour effet de remplacer ces termes anglais par des termes français, et/ou à
ajouter des termes français à un patron original en anglais. Malgré leur difficulté d’emploi, ces
exigences en « franglais » constituent en tout état de cause l’élément de preuve requis par
l’élément ASE_REQ.1.1D, alors que les exigences énoncées au § 5.2 du présent document ne
sont qu’une reformulation du contenu de cette section, fournie dans le but de faciliter la
compréhension de l’énoncé des exigences de sécurité des TI.
Dans l’identification des opérations, les raffinements qui consistent à substituer un terme à un
autre, les affectations et les sélections sont identifiés par le symbole « := ». Les raffinements qui
consistent à rajouter du texte sont identifiés par le symbole « + ». Les mises en forme sont
identifiées par le symbole « → » pour les substitutions et «  » pour les suppressions.
Les itérations sont identifiables à l’aide des étiquettes, comme cela est expliqué au § 5.1.2.
Les exigences de sécurité des TI sont présentées sous la forme suivante :
Pour chaque composant utilisé, les raffinements systématiques opérés sur les éléments de
ce composant,
Pour chaque élément du composant :
Le texte anglais original de l’élément, tel qu’extrait de [CC-02] ou [CC-03],
La liste des opérations effectuées sur l’élément.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 89 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
30
C I B L E D E S É C U R I T É
8.2 Exigences de sécurité pour la TOE
Cette section présente les exigences fonctionnelles de la TOE suivant une description formelle.
Le lien avec le chapitre 5 est réalisé en conservant le même titre pour les exigences
fonctionnelles concernées.
8.2.1 Exigences de contrôle des flux d’information
8.2.1.1 Fonctions de filtrage
8.2.1.1.1 FDP_IFC.2 – Filtrage complet des flux d’information
Raffinement systématique The TSF := les fonctions de filtrage
FDP_IFC.2.1 The TSF shall enforce the [assignment: information flow control SFP] on
[assignment: list of subjects and information] and all operations that cause
that information to flow to and from subjects covered by the SFP.
Affectation information flow control SFP := la politique de filtrage
Affectation list of subjects and information := les équipements des
réseaux interconnectés par l’IPS-Firewall (subjects), les
paquets IP (information)
Raffinement all operations that cause that information to flow to and from
subjects covered by the SFP := tous les transferts
(operations) de paquets IP entre les équipements des
réseaux interconnectés par l’IPS-Firewall
Mise en forme les équipements des réseaux interconnectés par l’IPS-
Firewall, les paquets IP et tous les transferts de paquets IP
entre les équipements des réseaux interconnectés par l’IPS-
Firewall
→ les paquets IP entrants
FDP_IFC.2.2 The TSF shall ensure that all operations that cause any information in the
TSC to flow to and from any subject in the TSC are covered by an
information flow control SFP.
Raffinement + mise en forme all operations that cause any information in the TSC to flow to
and from any subject in the TSC := tous les transferts de
paquets entre les équipements des réseaux interconnectés
par l’IPS-Firewall
→ tous les paquets IP entrants
Raffinement an information flow control SFP := la politique de filtrage
8.2.1.1.2 FDP_IFF.1.Filtrage – Fonctions de filtrage
Raffinement systématique The TSF := les fonctions de filtrage
Raffinement systématique information flow between a controlled subject and controlled
information via a controlled operation := les paquets IP
entrants
FDP_IFF.1.1 The TSF shall enforce the [assignment: information flow control SFP] based
on the following types of subject and information security attributes:
[assignment: list of subjects and information controlled under the indicated
SFP, and, for each, the security attributes].
Affectation information flow control SFP := la politique de filtrage
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 90 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
C I B L E D E S É C U R I T É
Raffinement + mise en forme subject and information := les équipements des réseaux
interconnectés par l’IPS-Firewall (subjects), les paquets IP
(information)
→ les paquets IP entrants
Affectation list of subjects and information controlled under the indicated
SFP, and, for each, the security attributes :=
a. L’interface de réception,
b. L’adresse IP source et destination du paquet et, partant de
là, la machine source et la machine destination du paquet,
c. Le numéro de protocole IP,
d. Si le protocole est TCP ou UDP : le port source et
destination,
e. Si le protocole est ICMP : les champs ‘type’ et ‘code’ du
message,
f. Si l’adresse IP source est associée à un utilisateur dans la
table des utilisateurs authentifiés : l’identité de l’utilisateur.
FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold:
[assignment: for each operation, the security attribute-based relationship that
must hold between subject and information security attributes].
Affectation for each operation, the security attribute-based relationship
that must hold between subject and information security
attributes :=
a. Préalablement à l’application des règles de filtrage, le
paquet est comparé à l’ensemble des connexions / pseudo-
connexions actuellement établies et ayant été autorisées par
les règles de filtrage ;
b. Si le paquet correspond à une de ces connexions /
pseudo-connexions, il est autorisé à passer sans être soumis
aux règles de filtrage ;
c. Sinon, le paquet est autorisé si l’action de la première règle
de filtrage applicable est ‘passer’.
FDP_IFF.1.3 The TSF shall enforce the [assignment: additional information flow control
SFP rules].
Affectation additional information flow control SFP rules :=
la règle complémentaire suivante : les règles de filtrage dont
l’action est ‘aucune’ ont pour unique objet la génération
d’enregistrements d’audit et ne rentrent pas en compte dans
le filtrage des paquets.
FDP_IFF.1.4 The TSF shall provide the following [assignment: list of additional SFP
capabilities].
Affectation list of additional SFP capabilities := aucune capacité
Mise en forme  de l’élément
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 91 de 109 Référence : na_tn_ciblesec_fr.sxw
20
25
C I B L E D E S É C U R I T É
FDP_IFF.1.5 The TSF shall explicitly authorise an information flow based on the following
rules: [assignment: rules, based on security attributes, that explicitly
authorise information flows].
Affectation rules, based on security attributes, that explicitly authorise
information flows :=
a. Les sessions associées à des protocoles nécessitant des
connexions filles sont suivies de manière à autoriser ces
connexions filles conformément à l’état de la session
principale ;
b. Des règles de filtrage implicites peuvent être générées par
le firewall en liaison avec la configuration d’autres fonctions
de sécurité. Ce sont les règles correspondant à :
i. l’administration à distance du firewall,
ii. l’authentification des utilisateurs,
iii. l’établissement de VPN.
FDP_IFF.1.6 The TSF shall explicitly deny an information flow based on the following
rules: [assignment: rules, based on security attributes, that explicitly deny
information flows].
Affectation rules, based on security attributes, that explicitly deny
information flows :=
a. L’action de la première règle de filtrage applicable est
‘bloquer’ ou ‘réinitialiser’ ;
b. Aucune règle de filtrage n’a autorisé le paquet.
8.2.1.2 Fonctions d’identification / authentification
8.2.1.2.1 FIA_UID.2 – Identification de l’utilisateur en vue de l’application de la politique de filtrage
Raffinement systématique The TSF := les fonctions d’identification / authentification
FIA_UID.2.1 The TSF shall require each user to identify itself before allowing any other
TSF-mediated actions on behalf of that user.
Raffinement + mise en forme before allowing any other TSF-mediated actions on behalf of
that user := avant d’autoriser +à travers l’ajout dans la table
des utilisateurs authentifiés suite à la réussite de
l’authentification,+ toute autre action transitant par la TSF
pour le compte de cet utilisateur.
→ avant de pouvoir l’ajouter à la table des utilisateurs
authentifiés
8.2.1.2.2 FIA_UAU.2 – Authentification de l’utilisateur en vue de l’application de la politique de filtrage
Raffinement systématique The TSF := les fonctions d’identification / authentification
FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before
allowing any other TSF-mediated actions on behalf of that user.
Raffinement + mise en forme before allowing any other TSF-mediated actions on behalf of
that user := avant d’autoriser +à travers l’ajout dans la table
des utilisateurs authentifiés+ toute autre action transitant par
la TSF pour le compte de cet utilisateur.
→ avant de l’ajouter à la table des utilisateurs authentifiés
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 92 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
C I B L E D E S É C U R I T É
8.2.1.2.3 FIA_UAU.5.Utilisateur – Mécanisme d’authentification des utilisateurs
Raffinement systématique The TSF := les fonctions d’identification / authentification
FIA_UAU.5.1 The TSF shall provide [assignment: list of multiple authentication
mechanisms] to support user authentication.
Affectation list of multiple authentication mechanisms := le mécanisme
basé sur le protocole SRP
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the
[assignment: rules describing how the multiple authentication mechanisms
provide authentication].
Affectation + mise en forme rules describing how the multiple authentication mechanisms
provide authentication := les règles définies par le protocole
SRP
→ le protocole SRP
8.2.1.3 Fonctions de chiffrement
8.2.1.3.1 FDP_IFC.1 – Chiffrement des flux d’information
Raffinement systématique The TSF := les fonctions de chiffrement
FDP_IFC.1.1 The TSF shall enforce the [assignment: information flow control SFP] on
[assignment: list of subjects, information, and operations that cause
controlled information to flow to and from controlled subjects covered by the
SFP].
Affectation information flow control SFP := la politique de chiffrement
Affectation + mise en forme list of subjects, information, and operations that cause
controlled information to flow to and from controlled subjects
covered by the SFP := les correspondants VPN et les
extrémités du trafic (côté TOE et côté correspondants VPN)
(subject), les datagrammes ESP entrants et les
datagrammes IP sortants couverts par une politique de
chiffrement (information), les réceptions de datagrammes
ESP entrants provenant des correspondants VPN et les
émissions de datagrammes IP sortants couverts par une
politique de chiffrement (operations)
→ les datagrammes ESP entrants et les datagrammes IP
sortants couverts par une règle de chiffrement
8.2.1.3.2 FDP_UCT.1 – Confidentialité du contenu des flux
Raffinement systématique The TSF := les fonctions de chiffrement
FDP_UCT.1.1 The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)] to be able to [selection: transmit, receive]
objects in a manner protected from unauthorised disclosure.
Affectation access control SFP(s) and/or information flow control SFP
(s) := la politique de chiffrement
Sélection transmit, receive := transmit and receive
Raffinement objects := des datagrammes IP
8.2.1.3.3 FDP_UIT.1 – Intégrité du contenu des flux
Raffinement systématique The TSF := les fonctions de chiffrement
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 93 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
C I B L E D E S É C U R I T É
FDP_UIT.1.1 The TSF shall enforce the [assignment: access control SFP(s) and/or
information flow control SFP(s)] to be able to [selection: transmit, receive]
user data in a manner protected from [selection: modification, deletion,
insertion, replay] errors.
Affectation access control SFP(s) and/or information flow control SFP
(s) := la politique de chiffrement
Sélection transmit, receive := transmit and receive
Raffinement user data := des datagrammes IP
Sélection modification, deletion, insertion, replay := modification,
insertion, replay
FDP_UIT.1.2 The TSF shall be able to determine on receipt of user data, whether
[selection: modification, deletion, insertion, replay] has occurred.
Raffinement user data := les datagrammes ESP entrants
Sélection modification, deletion, insertion, replay := modification,
insertion, replay
8.2.1.3.4 FDP_IFF.1.Chiffrement – Fonctions de chiffrement
Raffinement systématique The TSF := les fonctions de chiffrement
FDP_IFF.1.1 The TSF shall enforce the [assignment: information flow control SFP] based
on the following types of subject and information security attributes:
[assignment: the minimum number and type of security attributes].
Raffinement + mise en forme subject and information := les correspondants VPN et les
extrémités du trafic (côté TOE et côté correspondants VPN)
(subject), les datagrammes ESP entrants et les
datagrammes IP sortants couverts par une politique de
chiffrement (information)
→ les datagrammes ESP entrants et les datagrammes IP
sortants couverts par une règle de chiffrement
Affectation the minimum number and type of security attributes :=
Datagrammes ESP entrants :
a. L’index de sécurité (SPI),
Datagrammes IP sortants :
b. L’adresse IP source et destination du paquet et, partant de
là, la machine source et la machine destination du paquet,
c. Le type de protocole IP.
FDP_IFF.1.2 The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold:
[assignment: for each operation, the security attribute-based relationship that
must hold between subject and information security attributes].
Raffinement information flow between a controlled subject and controlled
information via a controlled operation := paquet ESP entrant
Affectation for each operation, the security attribute-based relationship
that must hold between subject and information security
attributes :=
a. un datagramme ESP entrant est rattachable à une SA
IPSec entrante active,
b. le paquet encapsulé dans le datagramme ESP correspond
aux critères de la règle de chiffrement associée à la SA
IPSec.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 94 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
C I B L E D E S É C U R I T É
FDP_IFF.1.3 The TSF shall enforce the [assignment: additional information flow control
SFP rules].
Affectation additional information flow control SFP rules := la règle
complémentaire suivante : un datagramme IP sortant couvert
par une règle de chiffrement sans SA IPSec sortante active
provoque une tentative de rénégociation. Si la négociation
échoue, le datagramme est détruit.
FDP_IFF.1.4 The TSF shall provide the following [assignment: list of additional SFP
capabilities].
Affectation list of additional SFP capabilities := les algorithmes
d’authentification et de chiffrement effectifs spécifiés par la
SA IPSec sortante associée à la première règle de
chiffrement applicable.
Mise en forme provide the following → appliquer aux datagrammes IP
sortants
FDP_IFF.1.5 The TSF shall explicitly authorise an information flow based on the following
rules: [assignment: rules, based on security attributes, that explicitly
authorise information flows].
Affectation rules, based on security attributes, that explicitly authorise
information flows := aucune règle
Mise en forme  de l’élément
FDP_IFF.1.6 The TSF shall explicitly deny an information flow based on the following
rules: [assignment: rules, based on security attributes, that explicitly deny
information flows].
Affectation rules, based on security attributes, that explicitly deny
information flows := aucune règle
Mise en forme  de l’élément
8.2.1.4 Fonctions d’établissement des SA
8.2.1.4.1 FTP_TRP.1.Corresp – Chemin de confiance avec les correspondants VPN
Raffinement systématique The TSF := les fonctions d’établissement des SA
FTP_TRP.1.1 The TSF shall provide a communication path between itself and [selection:
remote, local] users that is logically distinct from other communication paths
and provides assured identification of its end points and protection of the
communicated data from modification or disclosure.
Sélection remote, local := remote
Raffinement Itself := l’IPS-firewall
Raffinement remote users = les correspondants VPN
FTP_TRP.1.2 The TSF shall permit [selection: the TSF, local users, remote users] to
initiate communication via the trusted path.
Sélection the TSF, local users, remote users := the TSF and remote
users
Raffinement the TSF and remote users := l’IPS-firewall et les
correspondants VPN
Raffinement + L’établissement du chemin de confiance correspond à la
phase 1 du protocole IKE.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 95 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
C I B L E D E S É C U R I T É
FTP_TRP.1.3 The TSF shall require the use of the trusted path for [selection: initial user
authentication, [assignment: other services for which trusted path is
required]].
Sélection initial user authentication, [assignment: other services for
which trusted path is required] :=
a. initial user authentication,
b. [assignment: other services for which trusted path is
required]
Raffinement initial user authentication := l’authentification +mutuelle+
initiale +des extrémités du tunnel (phase 1 du protocole IKE)+
Affectation other services for which trusted path is required := la
négociation des SA IPSec (phase 2 du protocole IKE)
8.2.1.4.2 FIA_UAU.5.Corresp – Multiples mécanismes d’authentification des correspondants VPN
Raffinement systématique The TSF := les fonctions d’établissement des SA
FIA_UAU.5.1 The TSF shall provide [assignment: list of multiple authentication
mechanisms] to support user authentication.
Affectation list of multiple authentication mechanisms := les mécanismes
d’authentification suivants : certificats X509, clé pré-partagée
Raffinement user := le correspondant VPN d’un tunnel donné, dans le
cadre de l’authentification mutuelle initiale des extrémités de
ce tunnel lors de la phase 1 IKE.
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the
[assignment: rules describing how the multiple authentication mechanisms
provide authentication].
Affectation + mise en forme rules describing how the multiple authentication mechanisms
provide authentication := les règles du mécanisme
d’authentification spécifié pour le tunnel VPN
→ le mécanisme d’authentification spécifié pour le tunnel
VPN
Raffinement user := correspondant VPN
8.2.1.4.3 FPT_TDC.1 – Négociation des SA ISAKMP et IPSec
Raffinement systématique The TSF := les fonctions d’établissement des SA
FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret [assignment: list
of TSF data types] when shared between the TSF and another trusted IT
product.
Affectation list of TSF data types := les paramètres des SA ISKAMP et
IPSec
Raffinement consistently interpret les paramètres des SA ISKAMP et
IPSec := négocier les paramètres des SA ISKAMP et IPSec
Raffinement when shared between the TSF and another trusted IT
product := lors de l’établissement des tunnels VPN entre
l’IPS-Firewall et les correspondants VPN
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 96 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
C I B L E D E S É C U R I T É
FPT_TDC.1.2 The TSF shall use [assignment: list of interpretation rules to be applied by
the TSF] when interpreting the TSF data from another trusted IT product.
Affectation list of interpretation rules to be applied by the TSF :=
les règles suivantes :
a. Si l’IPS-Firewall est l’initiateur, proposer les paramètres de
la SA ISAKMP ou IPSec, et accepter les réponses aussi
rigoureuses qu’une des propositions faites ;
b. Si l’IPS-Firewall est le répondeur, n’accepter que les
propositions aussi rigoureuses qu’une des propositions
locales.
Raffinement interpreting the TSF data from another trusted IT product :=
négocier les paramètres des SA ISAKMP ou IPSec avec les
correspondants VPN
8.2.1.5 Fonctions de journalisation, d’audit et d’alarme
8.2.1.5.1 FAU_GEN.1 – Génération de données d’audit
Raffinement systématique The TSF := les fonctions de journalisation
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the [selection: choose one of: minimum, basic,
detailed, not specified] level of audit; and
c) [assignment: other specifically defined auditable events].
Sélection minimum, basic, detailed, not specified := not specified
Mise en forme  de l’item b)
Affectation other specifically defined auditable events := les événements
auditables énumérés dans le tableau au chapitre 5.2 après
FAU_GEN.1.2
FAU_GEN.1.2 The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity, and the
outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the PP/ST, [assignment: other audit
relevant information]
Raffinement subject identity := adresse IP source, et identité de
l’utilisateur (si elle est connue)
Affectation other audit relevant information := niveau d’alarme (si c’en est
une), les informations d’audit complémentaires énoncées
dans le tableau au chapitre 5.2
Mise en forme ‘‘Factorisation’’ de « niveau d’alarme (si c’en est une) »
8.2.1.5.2 FAU_GEN.2 – Génération de données d’audit
Raffinement systématique The TSF := les fonctions de journalisation
FAU_GEN.2.1 The TSF shall be able to associate each auditable event with the
identity of the user that caused the event.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 97 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
C I B L E D E S É C U R I T É
Raffinement user := administrateur
Raffinement auditable event := événement auditable associé aux
opérations d'administration de la sécurité
8.2.1.5.3 FAU_SAR.1 – Revue d’audit
Raffinement systématique The TSF := les fonctions d’audit
FAU_SAR.1.1 The TSF shall provide [assignment: authorised users] with the capability to
read [assignment: list of audit information] from the audit records.
Affectation authorised users := auditeurs
Affectation list of audit information := toutes les informations d’audit
Raffinement audit records := fichiers de trace
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to
interpret the information.
Raffinement audit records := fichiers de trace
Affectation user := auditeur
8.2.1.5.4 FAU_STG.3 – Action en cas de perte possible de données d’audit
Raffinement systématique The TSF := les fonctions de journalisation
FAU_STG.3.1 The TSF shall take [assignment: actions to be taken in case of possible audit
storage failure] if the audit trail exceeds [assignment: pre-defined limit].
Affectation actions to be taken in case of possible audit storage failure :=
une action parmi les suivantes :
a. Rotation des fichiers : les enregistrements d’audit les plus
récents effacent les enregistrements d’audit les plus anciens,
b. Stopper l'écriture des fichiers : les enregistrements d’audit
ne sont plus mémorisés,
c. Arrêter le Firewall : l’IPS-Firewall ne s'arrête pas
réellement mais il bloque l'ensemble des flux excepté les
sessions d’administration du Firewall Manager depuis le
réseau interne.
Raffinement audit trail := un fichier de trace
Affectation pre-defined limit := la taille limite maximum spécifiée
8.2.1.5.5 FAU_ARP.1.Alarmes – Réponse automatique aux alarmes
Raffinement systématique The TSF := les fonctions d’alarme
FAU_ARP.1.1 The TSF shall take [assignment: list of the least disruptive actions] upon
detection of a potential security violation.
Affectation list of the least disruptive actions :=
les actions suivantes :
a. Allumer, si ce n’est pas déjà fait, le voyant correspondant
au niveau d’alarme sur la face avant du boîtier appliance
firewall-VPN ;
b. Transmettre l’alarme aux moniteurs temps-réel
connectés ;
c. Envoyer l’alarme par e-mail aux destinataires spécifiés.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 98 de 109 Référence : na_tn_ciblesec_fr.sxw
25
30
C I B L E D E S É C U R I T É
Raffinement detection of a potential security violation := génération d’un
d’enregistrement d’audit auquel est attribué un niveau
d’alarme
8.2.1.6 Fonctions de programmation horaire
8.2.1.6.1 FMT_MOF.SSB – Programmation horaire du filtrage
Raffinement systématique The TSF := les fonctions de programmation horaire
FMT_MOF.SSB.1 The TSF shall [selection: determine the behaviour of, disable, enable, modify
the behaviour of] the functions [assignment: list of functions] according to the
rules [assignment: rules for the change of behaviour depending on time].
Sélection determine the behaviour of, disable, enable, modify the
behaviour of := modify the behaviour of
Affectation list of functions := les fonctions de filtrage
Affectation rules for the change of behaviour depending on time := la
règle suivante : le slot de filtrage actif est celui associé par la
grille horaire de filtrage à l'heure et au jour de la semaine
courants.
8.2.2 Exigences de protection contre les attaques Internet
8.2.2.1 Fonctions de prévention des intrusions
8.2.2.1.1 FAU_SAA.4 – Heuristiques des attaques complexes
Raffinement systématique The TSF := les fonctions de prévention des intrusions
FAU_SAA.4.1 The TSF shall be able to maintain an internal representation of the following
event sequences of known intrusion scenarios [assignment: list of
sequences of system events whose occurrence are representative of known
penetration scenarios] and the following signature events [assignment: a
subset of system events] that may indicate a potential violation of the TSP.
Raffinement internal representation := base de connaissance
Mise en forme the following event sequences of known intrusion scenarios
[assignment: list of sequences of system events whose
occurrence are representative of known penetration
scenarios] and the following signature events [assignment: a
subset of system events] that may indicate a potential
violation of the TSP
→ the following signature events and event sequences of
known intrusion scenarios [assignment: list of system events
or sequences of system events whose occurrence are
representative of known penetration scenarios] that may
indicate a potential violation of the TSP
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 99 de 109 Référence : na_tn_ciblesec_fr.sxw
35
40
45
C I B L E D E S É C U R I T É
Affectation list of system events or sequences of system events whose
occurrence are representative of known penetration
scenarios :=
les types d’attaque suivants :
a. paquets IP dont l’adresse source est incohérente avec
l’interface de réception,
b. paquets, datagrammes ou segments IP, ICMP, IGMP,
TCP ou UDP non conformes aux RFC, ou utilisation abusive
des possibilités offertes par ces protocoles,
c. commandes, requêtes ou réponses applicatives non
conformes à la syntaxe générale des commandes /
requêtes / réponses définie par les RFC, ou utilisation
abusive des possibilités offertes par ces protocoles,
d. attaques basées sur des vulnérabilités connues des
serveurs applicatifs,
e. tentatives de récupération d’information concernant la
configuration des serveurs applicatifs (fingerprinting, port
scanning, etc.),
f. dépassement du taux d’ouverture de connexions associé à
une règle de filtrage.
Raffinement potential violation of the TSP := attaque Internet potentielle
FAU_SAA.4.2 The TSF shall be able to compare the signature events and event
sequences against the record of system activity discernible from an
examination of [assignment: the information to be used to determine system
activity].
Raffinement signature events and event sequences := types d'attaque
présents dans la base de connaissance
Affectation information to be used to determine system activity := les
paquets IP entrants et sortants
Raffinement the record of system activity discernible from an examination
of les paquets IP entrants et sortants := l'état des différents
contextes associés à chaque paquet IP entrant et sortant
FAU_SAA.4.3 The TSF shall be able to indicate an imminent violation of the TSP when
system activity is found to match a signature event or event sequence that
indicates a potential violation of the TSP.
Raffinement imminent violation of the TSP := attaque Internet potentielle
Raffinement system activity := l'état d'un ou plusieurs contextes associés
à un paquet IP entrant
Raffinement signature event or event sequence that indicates a potential
violation of the TSP := type d'attaque présent dans la base de
connaissance
8.2.2.1.2 FAU_ARP.1.IPS – Réponse automatique aux attaques Internet potentielles
Raffinement systématique The TSF := les fonctions de prévention des intrusions
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 100 de 109 Référence : na_tn_ciblesec_fr.sxw
50
C I B L E D E S É C U R I T É
FAU_ARP.1.1 The TSF shall take [assignment: list of the least disruptive actions] upon
detection of a potential security violation.
Affectation list of the least disruptive actions :=
a. appliquer au paquet l’action associée au type de l’attaque,
b. si un niveau d’alarme est spécifié pour ce type d’attaque,
générer un enregistrement d’audit de l’événement, en lui
attribuant ce niveau d’alarme.
Raffinement potential security violation := attaque Internet potentiellement
véhiculée par un paquet IP entrant
8.2.3 Exigences de prévention de l’utilisation impropre
8.2.3.1 Fonctions de contrôle d’accès aux opérations d’administration de la sécurité
8.2.3.1.1 FMT_SMF.1 – Fonctions d'administration de la sécurité
Raffinement systématique The TSF := les fonctions d’administration de la sécurité
FMT_SMF.1.1 The TSF shall be capable of performing the following security management
functions: [assignment: list of security management functions to be provided
by the TSF].
Affectation list of security management functions to be provided by the
TSF :=
Les fonctions de contrôle d’accès aux opérations
d’administration de la sécurité ;
Les fonctions de protection des sessions d’administration
Les fonctions d’audit
Les fonctions de sauvegarde / restauration
8.2.3.1.2 FMT_SMR.1 – Rôle d’administrateur de la sécurité
Raffinement systématique The TSF := les fonctions de contrôle d’accès aux opérations
d’administration de la sécurité
FMT_SMR.1.1 The TSF shall maintain the roles [assignment: the authorised identified
roles].
Affectation the authorised identified roles := « administrateur » et « super
administrateur »
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Raffinement + en fonction des règles suivantes :
a. Il n’y qu’un seul super-administrateur, distinct des autres
administrateurs, et qui possède tous les droits ;
b. Les administrateurs sont ceux auxquels on a explicitement
attribué ce rôle.
8.2.3.1.3 FDP_ACC.2 – Contrôle d’accès complet aux opérations d’administration de la sécurité
Raffinement systématique The TSF := les fonctions de contrôle d’accès aux opérations
d’administration de la sécurité
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 101 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
C I B L E D E S É C U R I T É
FDP_ACC.2.1 The TSF shall enforce the [assignment: access control SFP] on [assignment:
list of subjects and objects] and all operations among subjects and objects
covered by the SFP.
Affectation access control SFP := la politique de contrôle d’accès aux
opérations d’administration de la sécurité
Affectation list of subjects and objects := les administrateurs (subjects),
les données et les fonctions de sécurité (objects)
Raffinement all operations among subjects and objects covered by the
SFP := toutes les opérations d’administration de la sécurité
Mise en forme les administrateurs, les données et les fonctions de sécurité
et toutes les opérations d’administration de la sécurité
→ toutes les opérations d’administration de la sécurité
effectuées par l’administrateur
FDP_ACC.2.2 The TSF shall ensure that all operations between any subject in the TSC and
any object within the TSC are covered by an access control SFP.
Raffinement + mise en forme all operations between any subject in the TSC and any object
within the TSC := toutes les opérations d’administration de la
sécurité entre les administrateurs et les données et les
fonctions de sécurité
→ toutes les opérations d’administration de la sécurité
effectuées par l’administrateur
Raffinement an access control SFP := la politique de contrôle d’accès aux
opérations d’administration de la sécurité
8.2.3.1.4 FMT_MOF.1 – Administration du comportement des fonctions de sécurité
Raffinement systématique The TSF := les fonctions de contrôle d’accès aux opérations
d’administration de la sécurité
FMT_MOF.1.1 The TSF shall restrict the ability to [selection: determine the behaviour of,
disable, enable, modify the behaviour of] the functions [assignment: list of
functions] to [assignment: the authorised identified roles].
Sélection determine the behaviour of, disable, enable, modify the
behaviour of := disable, enable, modify the behaviour of
Raffinement modify the behaviour of := effectuer, modifier la
programmation horaire
Affectation list of functions := les fonctions de sécurité du tableau ci-
dessous
Affectation the authorised identified roles := les administrateurs
Raffinement + en fonction des droits ci-dessous
8.2.3.1.5 FMT_MTD.1 – Administration des données de sécurité
Raffinement systématique The TSF := les fonctions de contrôle d’accès aux opérations
d’administration de la sécurité
FMT_MTD.1.1 The TSF shall restrict the ability to [selection: change_default, query, modify,
delete, clear, [assignment: other operations]] the [assignment: list of TSF
data] to [assignment: the authorised identified roles].
Sélection change_default, query, modify, delete, clear, [assignment:
other operations] := query, modify, clear
Affectation list of TSF data := les données de sécurité du tableau ci-
dessous
Affectation the authorised identified roles := les administrateurs
Raffinement + en fonction des droits ci-dessous
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 102 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
C I B L E D E S É C U R I T É
8.2.3.2 Fonctions de sauvegarde et de restauration
8.2.3.2.1 FMT_MTD.BRS – Sauvegarde et restauration des données de sécurité
Raffinement systématique The TSF := les fonctions de sauvegarde / restauration
FMT_MTD.BRS.1 The TSF shall be able to back up [assignment: list of TSF data] into a
storage device.
Affectation list of TSF data := les données de sécurité
Raffinement a storage device := le disque sur de la station
d’administration
FMT_MTD.BRS.2 The TSF shall allow restoration of TSF data backed up into a storage device.
Affectation TSF data := des données de sécurité
Raffinement a storage device := le disque sur de la station
d’administration
8.2.3.3 Qualité de la documentation d’exploitation
8.2.3.3.1 ADO_IGS.1 – Procédures d’installation, de génération et de démarrage
Pas d’opérations effectuées.
8.2.3.3.2 AGD_ADM.1 – Guides de l’administrateur
Pas d’opérations effectuées.
8.2.3.3.3 AGD_USR.1 – Guide de l’utilisateur
Pas d’opérations effectuées.
8.2.3.3.4 AVA_MSU.1 – Examen des guides
Pas d’opérations effectuées.
8.2.4 Exigences de protection de la TOE
8.2.4.1 Fonctions de protection des sessions d’administration
8.2.4.1.1 FPT_ITT.1 – Protection élémentaire du contenu des sessions d’administration
Raffinement systématique The TSF := les fonctions de protection des sessions
d’administration
FPT_ITT.1.1 The TSF shall protect TSF data from [selection: disclosure, modification]
when it is transmitted between separate parts of the TOE.
Raffinement TSF data := le contenu des sessions d’administration
Sélection disclosure, modification := disclosure, modification
Raffinement separate parts of the TOE := la station d’administration et le
boîtier appliance firewall-VPN
8.2.4.1.2 FTP_TRP.1.Admin – Chemin de confiance pour l’administration à distance
Raffinement systématique The TSF := les fonctions de protection des sessions
d’administration
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 103 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
C I B L E D E S É C U R I T É
FTP_TRP.1.1 The TSF shall provide a communication path between itself and [selection:
remote, local] users that is logically distinct from other communication paths
and provides assured identification of its end points and protection of the
communicated data from modification or disclosure.
Raffinement itself := l’IPS-firewall
Sélection remote, local := remote
Raffinement remote users := les administrateurs
FTP_TRP.1.2 The TSF shall permit [selection: the TSF, local users, remote users] to
initiate communication via the trusted path.
Sélection the TSF, local users, remote users := remote users
Raffinement remote users := les administrateurs
FTP_TRP.1.3 The TSF shall require the use of the trusted path for [selection: initial user
authentication, [assignment: other services for which trusted path is
required]].
Sélection initial user authentication, [assignment: other services for
which trusted path is required] := initial user authentication,
[assignment: other services for which trusted path is
required]
Raffinement initial user authentication := l’authentification +mutuelle+
initiale +de l’administrateur et de l’IPS-Firewall+
Affectation other services for which trusted path is required := les
opérations d’administration à distance de la sécurité
8.2.4.1.3 FIA_UAU.5.Admin – Mécanisme d’authentification des administrateurs
Raffinement systématique The TSF := les fonctions de protection des sessions
d’administration
FIA_UAU.5.1 The TSF shall provide [assignment: list of multiple authentication
mechanisms] to support user authentication.
Affectation list of multiple authentication mechanisms := le mécanisme
basé sur le protocole SRP
Raffinement user := administrateur
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the
[assignment: rules describing how the multiple authentication mechanisms
provide authentication].
Raffinement user := administrateur
Affectation + mise en forme rules describing how the multiple authentication mechanisms
provide authentication := les règles du protocole SRP
→ le protocole SRP
8.2.5 Autres exigences de sécurité de soutien
8.2.5.1 Autres fonctions de soutien
8.2.5.1.1 FCS_COP.1 – Fonctions cryptographiques
Raffinement systématique The TSF := les fonctions cryptographiques
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 104 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
C I B L E D E S É C U R I T É
FCS_COP.1.1 The TSF shall perform [assignment: list of cryptographic operations] in
accordance with a specified cryptographic algorithm [assignment:
cryptographic algorithm] and cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [assignment: list of
standards].
Affectation list of cryptographic operations := les opérations
cryptographiques du tableau ci-dessous
Affectation cryptographic algorithm := les algorithmes cryptographiques
 spécifiés ci-dessous
Affectation cryptographic key sizes := les tailles des clés
cryptographiques  spécifiées ci-dessous
Affectation list of standards := les standards énoncés ci-dessous
8.2.5.1.2 FPT_STM.1 – Base de temps fiable
Pas d’opérations effectuées.
8.2.5.2 Autres mesures d’assurance sécurité
8.2.5.2.1 ADV_FSP.1 – Spécifications fonctionnelles informelles
Pas d’opérations effectuées.
8.2.5.2.2 ADV_HLD.2 – Conception de haut niveau - identification des sous-systèmes dédiés à la
sécurité
Pas d’opérations effectuées.
8.2.5.2.3 ADV_LLD.1 – Conception de bas niveau descriptive des fonctions cryptographiques
Raffinement systématique the TSF := les fonctions cryptographiques
Raffinement systématique low level design + des fonctions cryptographiques
Raffinement systématique module + cryptographique
Raffinement systématique TOE security functional requirements + de la classe FCS
8.2.5.2.4 ADV_IMP.1 – Implémentation des fonctions cryptographiques
Raffinement systématique development + des fonctions cryptographiques
Raffinement systématique implementation + des fonctions cryptographiques
8.2.5.2.5 ALC_TAT.1 – Outils de développement des fonctions cryptographiques bien définis
Raffinement systématique development + des fonctions cryptographiques
Raffinement systématique implementation + des fonctions cryptographiques (sauf dans
ALC_TAT.1.2D et ALC_TAT.1.3C où les implementation
dependant options sont les options dépendant de
l’implémentation du compilateur)
8.2.5.2.6 ADV_RCR.1 – Démonstration de correspondance informelle
Pas d’opérations effectuées.
8.2.5.2.7 ATE_COV.1 – Éléments de preuve de la couverture
Pas d’opérations effectuées.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 105 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
C I B L E D E S É C U R I T É
8.2.5.2.8 ATE_FUN.1 – Tests fonctionnels
Pas d’opérations effectuées.
8.2.5.2.9 ATE_IND.2 – Tests indépendants - échantillonnage
Pas d’opérations effectuées.
8.2.5.2.10 ALC_FLR.3 – Correction d’anomalies systématique
Pas d’opérations effectuées.
8.2.5.2.11 AVA_SOF.1 – Évaluation de la résistance des fonctions de sécurité de la TOE
Pas d’opérations effectuées.
8.2.5.2.12 AVA_VLA.2 – Analyse de vulnérabilités indépendante
Pas d’opérations effectuées.
8.2.5.2.13 ACM_CAP.2 – Éléments de configuration
Pas d’opérations effectuées.
8.2.5.2.14 ADO_DEL.1 - Procédures de livraison
Pas d’opérations effectuées.
8.2.5.2.15 ALC_DVS.1 – Identification des mesures de sécurité
Pas d’opérations effectuées.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 106 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
C I B L E D E S É C U R I T É
9 ANNEXE C – EXIGENCES DE SÉCURITÉ EXPLICITEMENT
ÉNONCÉES
Cette section a pour objet l’énoncé des exigences de sécurité explicitement
Cette section a pour objet l’énoncé des exigences de sécurité explicitement
énoncées dans le but de compléter celles existant dans la partie 2 et 3 des
énoncées dans le but de compléter celles existant dans la partie 2 et 3 des
Critères Communs.
Critères Communs.
9.1 Introduction
Les exigences de sécurité explicitement énoncées dans la présente cible de sécurité sont toutes
de nature fonctionnelle.
9.2 FMT_MOF - Management of functions in TSF
Component levelling
FMT_MOF : Management of functions in TSF
1
SSB
FMT_MOF.SSB Scheduled security behaviour specifies automated capacity of the TSF to
change the security behaviour of the TOE according to a schedule or other timing conditions.
Management: FMT_MOF.SSB
a) Managing the rules that govern changing security behaviour according to time.
Audit: FMT_MOF.SSB
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) Basic: All modifications in the behaviour of the functions in the TSF.
9.2.1 FMT_MOF.SSB – Scheduled security behaviour
Hierarchical to: no other component.
FMT_MOF.SSB.1 The TSF shall [selection: determine the behaviour of, disable, enable,
modify the behaviour of] the functions [assignment: list of functions]
according to the rules [assignment: rules for the change of behaviour
depending on time].
Dependencies: FPT_STM.1 Reliable time stamps.
Application notes
Operations:
Assignment:
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 107 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25
C I B L E D E S É C U R I T É
In FMT_MOF.SSB.1, the PP/ST author should specify the functions which behaviour can be
modified according to the schedule. Examples include access control/information flow
control functions, identification/authentication functions, or auditing functions.
In FMT_MOF.SSB.1, the PP/ST author should specify the specify the rules that determine
the security behaviour of the TOE depending on time. An example of a rule is “users are
only allowed to log in from 8:00 am to 18:00 pm”.
Selection:
In FMT_MOF.SSB.1 the PP/ST author should select whether the TSF can determine the
behaviour of, disable, enable, and/or modify the behaviour of the security functions.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 108 de 109 Référence : na_tn_ciblesec_fr.sxw
5
C I B L E D E S É C U R I T É
9.3 FMT_MTD - Management of TSF data
Component levelling
FMT_MTD : Management of TSF data
1
BRS
2
3
FMT_MTD.BRS Backup and restoration of TSF data specifies the capacity to spare the
configuration of the TSF, or part of it, into a separate storage device, and to restore it thereafter.
Management: FMT_MTD.BRS
a) Managing the group of roles that can perform backup.
b) Managing the group of roles that can perform restoration.
Audit: FMT_MTD.BRS
The following actions should be auditable if FAU_GEN Security audit data generation is included
in the PP/ST:
a) Basic: Use of the backup functions.
b) Basic: Use of the restoration functions.
9.3.1 FMT_MTD.BRS – Backup and restoration of TSF data
Hierarchical to: no other component.
FMT_MTD.BRS.1 The TSF shall be able to back up [assignment: list of TSF data] into a
storage device.
FMT_MTD.BRS.2 The TSF shall allow restoration of TSF data backed up into a storage
device.
Dependencies: FMT_MTD.1
FMT_SMF.1
Application notes
Operations:
Assignment:
In FMT_MTD.BRS.1, the PP/ST author should specify the TSF data that can be backed up.
In particular, it should be specified whether partial backup is possible.
Version 1.7 © NETASQ 07/03/05 Confidentiel : usage interne et partenaires accrédités
Page 109 de 109 Référence : na_tn_ciblesec_fr.sxw
5
10
15
20
25