Nscib CC 0132539 ST

Machine Translated by Google
Solution RAN de ZTE
Cible de sécurité
INFORMATION LÉGALE
Copyright © 2019 ZTE CORPORATION.
1
Cible de sécurité Solution RAN ZTE
Tous les noms de sociétés, de marques et de produits sont des marques commerciales ou de service, ou des marques déposées ou de service, de ZTE.
CORPORATION ou de leurs propriétaires respectifs.
Ce document est fourni « tel quel », et toutes les garanties, représentations ou conditions expresses, implicites ou statutaires
sont déclinés, y compris, sans limitation, toute garantie implicite de qualité marchande, d'adéquation à un usage particulier
but, titre ou noncontrefaçon. ZTE CORPORATION et ses concédants de licence ne pourront être tenus responsables des dommages
résultant de l’utilisation ou de la confiance accordée aux informations contenues dans le présent document.
ZTE CORPORATION ou ses concédants de licence peuvent détenir des droits de propriété intellectuelle ou des applications en cours ou en attente.
couvrant l’objet de ce document. Sauf disposition expresse prévue dans toute licence écrite entre ZTE
CORPORATION et son titulaire de licence, l'utilisateur de ce document n'acquérira aucune licence sur le sujet.
ici.
Les utilisateurs peuvent visiter le site Web d'assistance technique de ZTE http://ensupport.zte.com.cn pour obtenir des informations connexes.
Le droit ultime d'interpréter ce produit appartient à ZTE CORPORATION.
Historique des révisions
Version Date Commentaire
0,1 23 octobre 2019 Première version
0,2 16 décembre 2019 Révision générale
0,3 14 janvier 2020 Révision générale appliquant les modifications

0,4 22 janvier 2020 Révision générale appliquant les modifications
0,7 27 juillet 2020 Révision mineure appliquant les modifications
0,9 6 août 2020 SPD et objectifs de sécurité ajoutés.

0,10 10 août 2020 Composants UME modifiés
0,11 14 août 2020 Mettre à jour les composants UME
0,12 17 août 2020 Réparer les opérations SFR
0,13 19 août 2020 Résoudre des problèmes mineurs
0,14 21 août 2020 Corrections mineures et note d'application ajoutées à

FTP_ITC.1/BBUUE.
0,15 27 août 2020 Changement de version UME et correctif mineur dans les opérations SFR.
0,16 1er septembre 2020 Modifications acceptées
0,17 29 septembre 2020 Section 6.2 mise à jour
0,18 10 octobre 2020 FTA_MCS.1/BBU et TSS mis à jour
0,19 22 octobre 2020 FTA_MCS.1/BBU Mise à jour de la limitation de base sur plusieurs
sessions simultanées
0,20 17 décembre 2020 Mis à jour après les commentaires de l'évaluateur.
0,21 19 janvier 2021 FAU_STG.4/BBU ajouté à la justification des exigences

fonctionnelles de sécurité et au tableau des dépendances.
0,22 4 février 2021 Versions corrigées des documents de procédure d'acceptation
[UGBBUACP] et [UGUMEACP].
2
Contenu
1 Introduction à la ST.................................................. .................................................................. .... 6
1.1 Référence ST ............................................... .................................................................. ...... 6
1.2 Référence de la TOE .................................................. .................................................................. ... 6
1.3 Présentation et utilisation de la TOE.................................................. ...................................... 6 1.3.1
Principales caractéristiques de sécurité..... .................................................................. ................................
7 1.3.2 Matériel/logiciel/micrologiciel nonTOE ........ .................................................................. 8
1.4 Description de la TOE.............................................. .................................................................. 8 1.4.1
Portée physique .............................................. .................................................................. .... 8 1.4.2 Portée
logique ............................................ .................................................................. ....... dix
2 Déclarations de conformité .................................................. ........................................ 11
3 Définition du problème de sécurité................................................... ................................ 13 3.1
Actifs .................. .................................................................. ...................................................... 13
3.2 Agents menaçants.................................................. .................................................................. ... 13 3.3
Menaces .................................................. .................................................................. ................ 13
3.4 Hypothèses............................................................ .................................................................. .... 14
4 Objectifs de sécurité............................................................ ...................................... 15 4.1 Objectifs de
sécurité pour le doigt de pied ................................................ ........................ 15 4.2 Objectifs de sécurité
pour l'environnement opérationnel ............... ...................... 15
5 Exigences de sécurité.................................................. ...................................... 17 5.1 Définition étendue
des composants...... .................................................................. .................. 17 5.2
Définitions .................................. .................................................................. ...................... 17
5.2.1 Sujets : .................................................. .................................................................. ......... 17 5.2.2
Opérations.................................. .................................................................. ................ 17 5.2.3
Objets .................................. .................................................................. .................................. 17 5.2.4
Attributs de sécurité .............. .................................................................. ........................ 18 5.2.5 Entité
BBU et AAU/RRU : ............... .................................................................. ........ 19 5.2.6 Entités
externes : ............................... .................................................................. .......... 19
5.3 Exigences fonctionnelles de sécurité.................................................. ...................... 20 5.4 Exigences
en matière d'assurance de sécurité .................. ...................................... 31 5.5 Justification des exigences
en matière d'assurance de la sécurité .................................................................. .32
6 Spécifications sommaires de la TOE............................................ .................................. 33
7 Justifications................................................................ .................................................................. ......... 37
7.1 Justification des objectifs de sécurité.................................................. ........................ 37 7.2 Justification
des exigences fonctionnelles de sécurité............... ...................................... 38 7.3
Dépendances .......... .................................................................. ...................................... 40
3
5
1 Présentation de ST
1.1 Référence ST
Titre Cible de sécurité de la solution ZTE RAN
Version 0,22
Date 04 février 2021
Auteur ZTE
1.2 Référence TOE
Nom de la TOE ZTE RAN
Version TOE V3.00.30.20P10
Composants de la TOE unité de bande de base ZXRAN V9200
(BBU) unité RF distante (RRU) ZXRAN R9105
ZXSDR R8998
ZXSDR R8862
ZXSDR R8852
ZXRAN R8894
ZXRAN R8854
ZXRAN R9212
ZXRAN R9214
ZXRAN R9222
Unité d'antenne active ZXRAN A9611
(AUA) ZXRAN A9815
ZXRAN A9631
ZXRAN A9622
Expert en gestion unifiée (UME), V16.20.30
Développeur ZTE
1.3 Présentation et utilisation de la TOE
La TOE est une solution système de réseau d'accès radio de nouvelle génération (NGRAN) pour le
réseau NR (nouvelle radio) plus un UME. La solution s'interface avec l'équipement utilisateur (UE) et
met en œuvre des fonctions telles que la gestion des ressources radio, la compression et le cryptage
des entêtes IP du flux de données, la sélection de la progression des attaches, le routage des
données du plan utilisateur, la planification et la transmission des données et la gestion de la mobilité.
L'UME est utilisé pour gérer le système via l'interface Web.
La TOE se compose de trois parties : une unité de bande de base (BBU), une unité RF distante (RRU)
soit une unité d'antenne active (AAU) et un expert en gestion unifiée (UME) :
• BBU est l'appareil qui traite la conversion analogiquenumérique du
signal;
• RRU est l'émetteurrécepteur de l'unité radio distante ;
• L'AAU intègre un module de traitement radiofréquence et une antenne ;
6
• UME est un système d'exploitation et de maintenance intelligent unifié pour RAN.
UME fournit la gestion intelligente de l'exploitation et de la maintenance du réseau, ainsi que le
déploiement à la demande et la mise à niveau du système en échelle de gris.
La TOE est reliée par trois réseaux :
• Réseau central : il s'agit du réseau interne du fournisseur.
considéré comme sûr dans cette évaluation.
• Un réseau de liaison : il s'agit d'un réseau externe et est considéré
peu sûr de lui dans cette évaluation.
• Un réseau de gestion IP : Il s'agit du réseau interne du fournisseur
et est considéré comme sécurisé dans cette évaluation.
La TOE et ces réseaux sont illustrés à la figure 1.
Figure 1 : La TOE dans son environnement
Le RAN qui est équivalent à gNodeB possède les fonctionnalités générales suivantes :
• Gestion des ressources radio : contrôle du support radio, contrôle d'admission radio ;
• Gestion de la mobilité des accès ;
• Compression d'entête IP et encapsulation du flux de données utilisateur ;
• Planification et transmission des messages de radiomessagerie ;
• Planification et transmission des messages diffusés ;
1.3.1 Principales fonctionnalités de sécurité
Les principales fonctionnalités de sécurité de la TOE sont :
7
• Gestion et utilisation sécurisées de la TOE, pour garantir que seul le personnel dûment autorisé
peut gérer et/ou utiliser la TOE ;
• Fournit une interaction sécurisée entre diverses parties de la TOE et entre la TOE et diverses
machines de l'environnement, de sorte que les données utilisateur et/ou les commandes de
gestion ne puissent pas être lues ou modifiées entretemps ;
• Fournit la journalisation et l'audit des actions des utilisateurs.
1.3.2 Matériel/logiciel/micrologiciel nonTOE
Les systèmes supplémentaires requis par la TOE sont : •
Des commutateurs L3 fournissant des services de filtrage au serveur UME et à la partie BBU de
le doigt de pied;
• Passerelle sécurisée : le RAN se connecte à une passerelle sécurisée (SEG) à l'aide d'IPSec. Le
SEG se connecte ensuite à un réseau sécurisé (Core) auquel se connecte AMF/UPF/UME ;
• Serveur UME : l'application UME nécessite pour fonctionner une plateforme composée du
matériel physique et du micrologiciel, le système d'exploitation.
• Fonction AMF assurant :
o Attribution d'un message de radiomessagerie au RAN ;
o Contrôle de sécurité ;
o Contrôle de la mobilité en état d'inactivité ;
o Contrôle du support UPF ;
o Chiffrement de la signalisation NAS et protection de l'intégrité.
• Fonction UPF offrant :
o Prise en charge des données du plan utilisateur de commutation de mobilité de l'UE ;
o Tampon de données de paquets de liaison descendante et prise en charge de la pagination en mode veille NGRAN
mode.
1.4 Description de la TOE
1.4.1 Portée physique
La TOE comprend les éléments suivants :
BBU Nom et version
Matériel V9200
Logiciel NS : V3.00.30.20P10
RRU Nom et version
Matériel R9105, R9212, R8998, R8894, R8854, R9222 ou
R9214
R8862 ou R8852
Logiciel V3.00.30.20P10
UQA Nom et version
Matériel A9611, A9815, A9631 ou A9622
Logiciel V3.00.30.20P10
8
HALEINE Nom et version
Logiciel Version du serveur UME ElasticNet UME V16.20.30
Serveur SSH (Apache SSHD v2.1.0)
Serveur SFTP (apachesshdcore v2.2.0)
Serveur LDAP (ApacheDS 2.0.0M24)
Les pièces matérielles de la TOE sont livrées par coursier, tandis que les pièces logicielles
sont soit installées dans le matériel, soit par les ingénieurs de ZTE. Les documents
suivants sont fournis par les ingénieurs de ZTE au client lors de l'installation de la TOE :
Document Format de version
[UGBBUACP] Procédure d'acceptation 0,4 PDF
[UGBBUCONF] Gestion de la configuration RAN 1.3 PDF
[UGBBUHWDES] Produit de réseau d'accès radio ZXRAN V9200
2.0 PDF
Description
[UGBBUHWINS] Matériel de réseau d'accès radio ZXRAN V9200
2.0 PDF
Installation
[UGBBUOPE] Gestion des éléments RAN 1.0 PDF
[UGBBUSWINS] Guide de mise en service de la station de base ZXRAN (Image
1.2 PDF
Brûlant)
[UGUMEACP] Procédure d'acceptation 0,3 PDF
[UGUMEINS] Guide d'installation et de déploiement d'UME 1.3 PDF
[UGUMELE] Événements du journal de sécurité 1.0 PDF
[UGUMEMML] Liste des commandes UME 1.0 PDF
[UGUMEOPELOG] Opération de gestion des journaux ElasticNet UME
R1.0 PDF
Guide
[UGUMEOPEOAOG] Fonctionnement du service API ouverte ElasticNet UME
R1.0 PDF
Guide
[UGUMEOPESMOG] Gestion de la sécurité ElasticNet UME
R1.0 PDF
Guide d'opération
[UGUMEPRE] Description des preuves de protection de l'intégrité du logiciel UME 1.0 PDF
[UGUMESPM] Manuel des paramètres de sécurité 1.0 PDF
[UGUMEUPG] Guide de mise à niveau UME 1.12 PDF
Installation matérielle du ZXRAN A9622E S35 5G 1.0 PDF
Guide d'installation matérielle de l'unité d'antenne active ZXRAN A9631 S26 5G 1.0 PDF
Installation matérielle de l'unité d'antenne active ZXRAN A9815 5G 1.0 PDF
Installation matérielle de l'unité d'antenne active ZXRAN A9611 S35 5G 1.0 PDF
Installation matérielle de l'unité radio à distance ZXRAN R9105 S26 5G 1.0 PDF
Installation matérielle de l'unité radio à distance ZXRAN R9105 S35 5G 1.0 PDF
Guide d'installation matérielle de l'unité distante macro radio ZXRAN R9212E 1.0 PDF
Installation matérielle de l'unité distante macro radio ZXRAN R9214E 1.0 PDF
Guide d'installation matérielle de l'unité distante macro radio ZXRAN R9222 1.0 PDF
Installation matérielle de l'unité radio à distance macro ZXSDR R8862A 1.0 PDF
Matériel d'unité radio distante multichemins ZXSDR R8998E S2600 TDD 1.0 PDF
9
Installation
Matériel d'unité radio distante multichemins ZXSDR R8998E S3700 TDD
1.0 PDF
Installation
Installation matérielle de l'unité radio à distance macro ZXSDR R8852E 1.0 PDF
Installation matérielle de l'unité distante macro radio ZXSDR R8854E 1.0 PDF
1.4.2 Portée logique
L'architecture du système de la TOE est décrite dans la figure 1. La TOE offre les fonctionnalités de sécurité
suivantes :
• L'identification et l'authentification des utilisateurs sont appliquées, les utilisateurs doivent donc être
authentifié par mot de passe avant d'utiliser ou de gérer la TOE. Les sessions utilisateur sont
surveillées et les mots de passe sont vérifiés pour appliquer une authentification sécurisée ;
• Le contrôle d'accès est strictement appliqué aux utilisateurs de la TOE en fonction de leur rôle et de la
politique de contrôle d'accès ;
• Des fonctionnalités de gestion des utilisateurs sont fournies pour contrôler les utilisateurs et leurs
attributs (rôle, mot de passe, temps d'inactivité, verrouillage du compte, etc.) ;
• Les communications de la TOE permettent d'identifier ses points finaux et sont protégées contre toute
modification ou divulgation. Cette protection inclut la communication entre les parties de la TOE
(UME, BBUSEG, BBUBBU) et la communication entre la TOE et les entités externes (BBUUE) ;
• Les activités des utilisateurs sur UME sont enregistrées pour garantir l'entière responsabilité des actions
de l'utilisateur, et la trace du journal est protégée contre toute modification non autorisée. La TOE
offre aux administrateurs des fonctionnalités de révision des journaux.
dix
2 Déclarations de conformité
Cette ST est conforme
à : CC, version 3.1R5, telle que définie par [CCp1], [CCp2], [CCp3] et [CEMe].
CC Part 2 comme conforme à CC Part
2 CC Part 3 comme conforme à CC Part 3
Ce ST n'est conforme à aucun profil de protection.
Ce ST est conforme à EAL 3+ALC_FLR.2 et à aucun autre package.
11
3 Définition du problème de sécurité
Cette section décrit les actifs, les agents de thread et les threads de la TOE.
3.1 Actifs
A.USER_DATA Données utilisateur provenant d'un appareil utilisateur transmises par la
TOE.
A.TSF_DATA Données TSF stockées et gérées par l'UME et la BBU et utilisées pour
appliquer le mécanisme de sécurité, tel que les mots de passe utilisateur
stockés, les attributs utilisateur ou les clés de cryptage des canaux de
confiance. Ces données ne seront modifiées que par les utilisateurs
disposant de A.ADMIN_ACCESS
A.ADMIN_ACCESS Accès administratif à l'UME et au BBU.
A.TSF_ACTIVITY_LOGS Enregistrements des journaux des utilisateurs et des administrateurs générés par la TSF.
3.2 Agents menaçants
TA.REMOTE Un attaquant ayant accès au réseau de liaison qui est
connecté à la TOE et/ou avec accès à l’air
réseau entre l’UE et RRU/AAU. Cet agent ne
avoir un accès autorisé à l’UME ou au BBU.
TA.UTILISATEUR Un attaquant disposant d'un accès autorisé à l'UME ou au
BBU, mais sans aucun droit administratif.
3.3 Des menaces
T.COMMUNICATION_CH TA.REMOTE peut être en mesure de divulguer ou de modifier les données
A.USER_DATA ou A.TSF_DATA lors de leur transmission via des réseaux
non sécurisés.
T.UNAUTHENTICATED_USER TA.REMOTE peut être capable de contourner l'utilisateur
authentification et pour accéder à l'UME ou à la BBU et
effectuer des actions d'administration (A.ADMIN_ACCESS) sur la TOE
et modifier A.TSF_DATA .
T.UNAUTHORIZED_ADMIN TA.USER peut être capable de contourner la politique de contrôle d'accès
de l'UME ou du BBU et d'effectuer des actions administratives
(A.ADMIN_ACCESS) sans droits d'administrateur et de modifier
A.TSF_DATA.
T.UNDETECTED_ACTIVITY TA.REMOTE ou TA.USER peuvent tenter ou effectuer des actions
abusives sur l'UME ou la BBU sans
13
sensibilisation de l'administrateur (A.TSF_ACTIVITY_LOGS).
3.4 Hypothèses
A.TIME L’environnement fournira un horodatage fiable pour la TOE.
A.UME_TRUSTED_NETWORK L'UME est déployé dans un environnement contrôlé ; dans la salle d'équipement
de l'opérateur dans un réseau de confiance. L'UME est séparé du
réseau central et du réseau de gestion IP, de sorte que seul le trafic
réseau autorisé est autorisé.
A.PROTECTION_PHYSIQUE Les équipements matériels des serveurs BBU et UME sont placés
dans un espace sûr et contrôlable. Ces équipements sont entretenus
et utilisés uniquement par du personnel autorisé.
A. ADMINISTRATEURS Le personnel travaillant en tant qu'administrateurs autorisés est digne
de confiance et formé pour l'administration de la TOE.
A.UME_PLATFORME Le matériel sousjacent, le micrologiciel, le système d'exploitation et
les autres logiciels non TOE de l'UME fonctionnent correctement.
A.UME_CLIENT L'administrateur utilise un terminal de gestion à distance sécurisé
pour accéder à distance à la TOE. Le client est à jour en ce qui
concerne les mises à niveau de sécurité et la prise en charge
cryptographique.
14
4 Objectifs de sécurité
Les objectifs de sécurité décrivent la manière dont les menaces décrites dans la section précédente
seront traitées. Il est divisé en :
Les objectifs de sécurité de la TOE, décrivant ce que la TOE fera pour
faire face aux menaces
Les objectifs de sécurité pour l'environnement opérationnel, décrivant
ce que les autres entités doivent faire pour faire face aux menaces
Une justification selon laquelle la combinaison de tous ces objectifs de sécurité répond effectivement
aux menaces peut être trouvée dans la section 7.1 de cet objectif de sécurité.
4.1 Objectifs de sécurité pour la TOE
O.SECURE_COMUNICATION La TOE doit fournir les moyens d'établir les canaux de
communication sécurisés suivants entre : 1. L'abonné (UE)
et la BBU ;
2. Une BBU et une autre BBU ;
3. Une BBU et la passerelle de confiance du noyau
réseau;
4. L'UME et le client UME.
O.USER_AUTHENTICATION La TOE doit appliquer l'authentification de l'utilisateur sur tous
accès utilisateur au BBU et à l'UME.
O.ACCESS_CONTROL La TOE doit mettre en œuvre un cadre d’autorisation flexible
basé sur les rôles. Chaque rôle permet à un utilisateur de
effectuer certaines actions, et la TOE doit s'assurer que les
utilisateurs ne peuvent effectuer des actions que lorsqu'ils
disposent d'un rôle qui leur permet d'effectuer une telle action.
O.AUDIT La TOE doit appliquer la journalisation des actions des
utilisateurs et fournir des capacités d'audit à l'administrateur.
rôle.
4.2 Objectifs de sécurité pour l’environnement opérationnel
VOUS.TIME L'environnement de la TOE doit fournir une heure fiable via le
service NTP.
OE.UME_TRUSTED_NETWORK Le segment de réseau utilisé par l'UME doit être sécurisé et assurer la
séparation des autres réseaux via une passerelle de confiance. La
passerelle sécurisée (SEG) doit être capable de fournir une
communication sécurisée avec la BBU.
OE.PHYSICAL_PROTECTION Les équipements matériels des serveurs BBU et UME doivent être placés
dans un espace sûr et contrôlable. Ces
15
l'équipement doit être entretenu et utilisé uniquement par du
personnel autorisé.
OE.ADMINISTRATEURS Le personnel travaillant en tant qu'administrateurs autorisés doit
être digne de confiance et soigneusement formé pour l'administration
de la TOE et suivra les instructions d'utilisation de la TOE.
VOUS.UME_PLATFORM Le matériel sousjacent, le micrologiciel, le système d'exploitation
et les autres logiciels non TOE de l'UME doivent fonctionner
correctement.
OE.UME_CLIENT L'administrateur de l'UME doit utiliser une télécommande sécurisée
terminal de gestion pour l'accès à distance à la TOE.
Le client doit être à jour concernant les mises à niveau de sécurité
et la prise en charge cryptographique.
16
5 Exigences de sécurité
5.1 Définition étendue des composants
Aucun composant étendu n’est défini.
5.2 Définitions
Les termes suivants sont utilisés dans les exigences de sécurité :
5.2.1 Sujets:
• S.UMEuser : les utilisateurs ayant accès à l'UME et qui sont responsables de la gestion de la
TOE et qui sont connectés via le réseau de gestion IP ;
• Utilisateur S.BBU : les utilisateurs ayant accès à la BBU et qui sont responsables de la gestion
de la BBU et qui sont connectés via le réseau local.
5.2.2 Opérations
• OP.lockUnlockUser : pour déverrouiller ou verrouiller un utilisateur. Un utilisateur verrouillé ne peut pas
connectezvous à l'UME ou au BBU ;
• OP.lockUnlockRole : pour verrouiller ou déverrouiller un rôle. Un rôle verrouillé empêche les
utilisateurs qui disposent uniquement du rôle verrouillé d'utiliser l'UME, à l'exclusion des
fonctions suivantes :
o Changer son mot de passe ;
o Déconnectezvous de l'UME ;
o Afficher les informations sur la version UME ;
o Régler le fuseau horaire et l'heure d'été ;
o Changer la langue d'affichage.
• OP.enableDisableUser : pour activer ou désactiver un compte utilisateur. Un handicapé
le compte utilisateur ne peut pas se connecter à l'UME ou au BBU ;
• OP.userManagement : pour exécuter des fonctions de gestion des utilisateurs, notamment
l'ajout, la suppression d'utilisateurs ou la modification des attributs des utilisateurs depuis
UME et BBU ;
• OP.logReview : pour consulter les journaux générés par l'UME ;
• OP.RuleManagement : pour exécuter des fonctions de gestion des règles de sécurité, qui
incluent des fonctions de gestion telles que l'ajout, la suppression ou la modification d'une
règle de sécurité ;
• OP.idleTimeout : pour définir la durée pendant laquelle un utilisateur peut rester inactif
avant d'être déconnecté de l'UME ou du BBU.
5.2.3 Objets
• O.user : cet objet comprend toutes les informations du compte utilisateur. Les champs spécifiques
peuvent être consultés dans la section suivante car ils sont considérés comme des attributs
de sécurité ;
• O.role : cet objet inclut toutes les informations de l'objet rôle. Les champs spécifiques peuvent
être consultés dans la section suivante car ils sont considérés comme des attributs de
sécurité ;
17
• O.rule : cet objet regroupe toutes les informations de la règle de sécurité. Les champs spécifiques peuvent
être consultés dans la section suivante car ils sont considérés comme des attributs de sécurité ;
• O.setting : cet objet inclut toutes les informations des paramètres communs de sécurité. Les champs
spécifiques peuvent être consultés dans la section suivante car ils sont considérés comme des attributs
de sécurité.
5.2.4 Attributs de sécurité
• Règle
o Rule.passwordExpirationDate : est la date d'expiration du mot de passe de l'utilisateur s'il est
utilisé ;
o Rule.passwordHistoryNumber : le numéro d'historique des derniers mots de passe. Lorsqu'il est
défini, l'utilisateur ne peut pas utiliser les mots de passe de cet historique de mots de passe
lors de la modification du mot de passe.
o Rule.allowedIPs : est la liste des adresses IP sources autorisées pour que l'utilisateur puisse se
connecter. Si la connexion est demandée à partir d'autres adresses IP, l'accès est refusé ;
o Rule.allowedWorkSchedule : est l'horaire accepté pour la connexion de l'utilisateur. En dehors
de ce délai, l'utilisateur n'est pas autorisé
pour l'UME ;
o Rule.authenticationAttempts : est le nombre maximum de tentatives d'authentification autorisées
pour l'utilisateur avant de verrouiller son compte.
o Rule.lockedPeriod : est la période pendant laquelle le compte utilisateur restera verrouillé ;
• Réglage
o Setting.idleTimeout : est la durée pendant laquelle l'utilisateur peut rester inactif avant d'être
déconnecté de l'UME ou du BBU.
• Utilisateur
o User.username : Identifiant unique de l'utilisateur ;
o User.password : le mot de passe de l'utilisateur ;
o User.passwordHistory : l'historique des modifications du mot de passe de l'utilisateur ;
o User.rolesList : est la liste des rôles de l'utilisateur ;
o User.rule : est la règle de sécurité de l'utilisateur ;
o User.isLocked : ceci indique si le compte utilisateur est verrouillé ou non.
Seuls les utilisateurs non verrouillés sont autorisés à se connecter ;
o User.isEnable : ceci indique si l'utilisateur est activé et peut être utilisé ou non. Seuls les
utilisateurs activés sont autorisés à se connecter ;
• Rôles
o Role.type(UME) : il peut s'agir de l'un des éléments suivants :
• Administrateur de sécurité : ce rôle a le droit d'effectuer la maintenance des données
de sécurité, mais il ne dispose d'aucun privilège professionnel ;
• Administrateur : ce rôle dispose d'un accès complet et illimité au système, à
l'exception de la maintenance des informations de sécurité ;
• Maintenance : ce rôle a un accès complet au système et à son réseau géré, à
l'exception de la maintenance du système d'information de sécurité et de
maintenance ;
18
• Opérateur : ce rôle a le droit de visualiser les informations du réseau et
d'effectuer la maintenance normale, mais il ne peut pas modifier les
informations sensibles du système ;
• Superviseur : ce rôle a le droit de visualiser les informations du système.
o Role.type(BBU) : il peut s'agir de l'un des éléments suivants :
• Administrateur utilisateur super root, qui n'est pas limité par
expiration du mot de passe ;
• Maintenance autre utilisateur, qui ne peut pas créer ou modifier les
informations utilisateur et est limité par l'expiration du mot de passe ;
• Ordinaire – utilisateur ordinaire sans autorisation de lecture, d'écriture ou
d'exécution pour les données du nœud de gestion de la sécurité et
disposant d'une autorisation en lecture seule pour d'autres nœuds tels
que le service commun radio, l'appareil, le réseau de transport, les
modèles de fonction gNode.
o Role.islocked : ceci indique si le rôle est verrouillé ou non. Lorsqu'un
Le rôle est verrouillé, les utilisateurs avec ce rôle ne peuvent pas utiliser UME.
5.2.5 Entité BBU et AAU/RRU :
L'AAU/RRU et le BBU sont connectés via une fibre optique et communiquent via le protocole
standard CPRI. La figure suivante montre le format du paquet CPRI :
5.2.6 Entités externes :
• UE : équipement utilisateur utilisé par les abonnés pour se connecter aux BBU via le réseau
backhaul.
• Autre BBU : il s'agit d'une autre BBU travaillant dans l'environnement de la TOE mais remplissant
la même fonction que la BBU de la TOE.
• Passerelle sécurisée (SEG) : est la passerelle reliant l'UME du réseau central aux BBU.
Les conventions de notation suivantes sont utilisées dans les exigences. Les opérations sont indiquées
en gras, sauf les raffinements, qui sont indiqués en italique gras. En général
19
des améliorations ont été apportées pour clarifier les exigences et/ou les rendre plus lisibles.
Les itérations ont été indiquées en ajoutant trois lettres au nom du composant.
5.3 Exigences fonctionnelles de sécurité
Les exigences fonctionnelles de sécurité concernent l’UME et le BBU. Étant donné que l'AAU/RRU qui
améliore uniquement la formation de faisceaux 3D pour une couverture cubique ne contient pas de
fonction de sécurité, cette section ne décrit pas les exigences en matière de fonction de sécurité de
l'AAU et de la RRU.
5.3.1 Exigences fonctionnelles de sécurité pour l'UME
5.3.1.1 FIA_UID.2/UME Identification de l'utilisateur avant toute action
FIA_UID.2.1 La TSF doit exiger que chaque utilisateur S.UME soit identifié avec succès avant
d'autoriser toute autre action médiée par la TSF au nom de cet utilisateur.
5.3.1.2 FIA_UAU.2/UME Authentification de l'utilisateur avant toute action
FIA_UAU.2.1 La TSF doit exiger que chaque utilisateur S.UME soit authentifié avec succès avant
5.3.1.3 Gestion des échecs d'authentification FIA_AFL.1/UME
FIA_AFL.1.1 La TSF doit détecter lorsqu'un entier positif configurable par l'administrateur de sécurité
entre 3 et 20 (Rule.authenticationAttempts, par défaut 3) des tentatives d'authentification infructueuses
liées à l'authentification de l'utilisateur S.UME se produisent.
FIA_AFL.1.2 Lorsque le nombre défini de tentatives d'authentification infructueuses est atteint, la TSF
verrouille le compte utilisateur S.UME.
• Jusqu'à ce qu'il soit déverrouillé par l'administrateur de sécurité, ou
• Jusqu'à une heure configurable par l'administrateur de sécurité (Rule.lockedPeriod)
sont passées, si le compte n'a pas été verrouillé de manière permanente.
5.3.1.4 FIA_SOS.1/UME Vérification des secrets
FIA_SOS.1.1 La TSF doit fournir un mécanisme pour vérifier que User.password répond :
• Au moins 8 caractères dont quatre types : chiffre, lettre majuscule,
lettre minuscule, autres caractères ;
• Ne peut pas être identique au nom d'utilisateur, au nom d'utilisateur inversé1 ou à un
mot de dictionnaire de mot de passe commun ;
• Le nouveau mot de passe ne peut pas être identique à l'un des derniers mots
de passe (Rule.passwordHistoryNumber) définis dans
User.passwordHistory.
1 Si le nom d'utilisateur est modifié, « gnahc » n'est pas autorisé
20
5.3.1.5 Terminaison initiée par FTA_SSL.3/UME TSF
FTA_SSL.3.1 La TSF doit terminer une session interactive
• Après une période d'inactivité égale au temps configuré
(Paramètre.idleTimeout);
• lorsqu'un des rôles d'utilisateur dans la liste des utilisateurs (User.rolesList) est verrouillé ou modifié
alors que l'utilisateur est connecté.
5.3.1.6 FTA_MCS.1/UME Limitation de base sur plusieurs sessions simultanées
FTA_MCS.1.1 La TSF doit limiter le nombre maximum de sessions simultanées appartenant au même
utilisateur S.UME.
FTA_MCS.1.2 La TSF imposera, par défaut, une limite de 1 session par utilisateur S.UME.
5.3.1.7 FAU_GEN.1/UME Génération de données d'audit
FAU_GEN.1.1 L'UME doit être capable de générer un enregistrement d'audit des événements auditables
suivants :
a) Démarrage et arrêt des fonctions d'audit ;
b) Tous les événements auditables pour le niveau d'audit non spécifié ; et
c) Les événements auditables suivants :
• Authentification de l'utilisateur S.UME (journal de sécurité) ;
• OP.lockUnlockUser (journal de sécurité) ;
• OP.enableDisableUser (journal des opérations) ;
• OP.userManagement (journal des opérations) ;
• OP.ruleManagement (journal des opérations) ;
• OP.idleTimeout (journal des opérations).
FAU_GEN.1.2 La TSF doit enregistrer dans chaque enregistrement d'audit au moins les informations
suivantes :
a) Date et heure de l'événement, type d'événement, identité du sujet (le cas échéant) et résultat
(succès ou échec) de l'événement ; et
b) Pour chaque type d'événement d'audit, sur la base des définitions d'événements auditables du
composants fonctionnels inclus dans le PP/ST, aucun.
Note d'application : Le démarrage et l'arrêt des fonctions d'audit ne sont pas explicitement enregistrés,
cependant la fonctionnalité de journalisation est activée au démarrage et ne peut pas être désactivée.
5.3.1.8 Revue d'audit FAU_SAR.1/UME
FAU_SAR.1.1 La TSF doit fournir à l'utilisateur S.UME avec administrateur ou administrateur de sécurité
dans User.rolesList la capacité de lire tous les enregistrements de journal à partir des enregistrements
d'audit.
FAU_SAR.1.2 La TSF doit fournir les enregistrements d'audit d'une manière permettant à l'utilisateur
d'interpréter les informations.
21
5.3.1.9 FAU_STG.1/UME Stockage protégé de la piste d'audit
FAU_STG.1.1 La TSF doit protéger les enregistrements d'audit stockés dans la piste d'audit contre toute
suppression non autorisée.
FAU_STG.1.2 La TSF doit être capable d' empêcher les modifications non autorisées des enregistrements
d'audit stockés dans la piste d'audit.
5.3.1.10 FAU_STG.4/UME Prévention de la perte de données d'audit
FAU_STG.4.1 La TSF doit écraser les enregistrements d'audit stockés les plus anciens2 si le
la piste d'audit est pleine.
Note d'application : les enregistrements d'audit peuvent être exportés vers un serveur de sauvegarde.
5.3.1.11 FTP_TRP.1/UMEClient Chemin de confiance
FTP_TRP.1.1 La TSF doit fournir un chemin de communication entre ellemême et l'utilisateur S.UME qui
est logiquement distinct des autres chemins de communication et assure l'identification assurée de ses
points d'extrémité et la protection des données communiquées contre la modification et la divulgation.
FTP_TRP.1.2 La TSF doit permettre à l'utilisateur S.UME d'initier la communication via le chemin approuvé.
FTP_TRP.1.3 La TSF doit exiger l'utilisation du chemin de confiance pour l'authentification initiale de
l'utilisateur et toutes les fonctions de gestion UME définies dans FMT_SMF.1/UME.
5.3.1.12 FIA_ATD.1/UME Définition de l'attribut utilisateur
FIA_ATD.1.1 La TSF doit maintenir la liste suivante d'attributs de sécurité appartenant à un utilisateur
S.UME individuel :
• Utilisateur.nom d'utilisateur ;
• Utilisateur.mot de passe ;
• Utilisateur.passwordHistory ;
• User.rolesList ;
• Utilisateur.rule ;
• Utilisateur.isLocked ;
• Utilisateur.isEnable ;
5.3.1.13 Rôles de sécurité FMT_SMR.1/UME
FMT_SMR.1.1 La TSF doit maintenir les rôles :
o Administrateur de sécurité
l' administrateur
o Entretien
o Opérateur
2 L'opération a été réalisée pour « ne prendre aucune autre mesure », et cela a ensuite été
affiné pour rendre la phrase plus lisible.
22
o Superviseur
FMT_SMR.1.2 La TSF doit pouvoir associer des utilisateurs à des rôles.
5.3.1.14 FMT_SMF.1/UME Spécification des fonctions de gestion
FMT_SMF.1.1 La TSF doit être capable d'exécuter les fonctions de gestion suivantes : Fonction de gestion
OP.ruleManagement > Relatif à SFR
User.Rule.allowedIPs FDP_ACF.1/UME
Définissez si un utilisateur (à qui la règle est attribuée) ne peut se connecter
qu'à partir de certaines adresses IP, et si oui, quelles adresses IP.
OP.idleTimeout > Setting.idleTimeout FTA_SSL.3/UME
Définissez la durée pendant laquelle les utilisateurs peuvent rester connectés lorsqu'ils sont inactifs.
OP.ruleManagement > FDP_ACF.1/UME
User.Rule.allowedWorkSchedule
Définissez si un utilisateur (à qui la règle est attribuée) est autorisé à travailler
uniquement à certaines heures et, si oui, à quelles heures.
OP.ruleManagement > FIA_AFL.1/UME
User.Rule.authenticationAttempts
Définir le nombre de tentatives d'authentification infructueuses autorisées
OP.ruleManagement > User.Rule.lockedPeriod FIA_AFL.1/UME
Définir la durée pendant laquelle un compte (attribué à la règle) reste verrouillé
OP.lockUnlockUser > User.isLocked FIA_AFL.1/UME
Déverrouiller un compte utilisateur
OP.ruleManagement > FDP_ACF.1/UME

User.Rule.passwordExpirationDate
Définir si le mot de passe d'un utilisateur (attribué à la règle) expire après un
certain temps et, si oui, après combien de temps
OP.ruleManagement > Rule.passwordHistoryNumber Définissez la FIA_SOS.1/UME
longueur de l'historique des mots de passe conservé pour empêcher les
utilisateurs d'utiliser le même mot de passe. Par exemple, s'il est défini sur 3,
les utilisateurs ne peuvent pas utiliser les 3 derniers mots de passe
OP.userManagement > User.rolesList FMT_SMR.1/UME
Ajouter ou supprimer des rôles vers/des utilisateurs
OP.userManagement FIA_ATD.1/UME
Créer, modifier et supprimer des comptes d'utilisateurs FIA_SOS.1/UME
OP.enableDisableUser > User.isEnable FIA_ATD.1/UME
Désactiver/activer les comptes d'utilisateurs
OP.lockUnlockRole FTA_SSL.3/UME
Verrouiller/déverrouiller les rôles
OP.logReview FAU_SAR.1/UME
Examen du journal
5.3.1.15 FDP_ACC.2/UME Contrôle d'accès complet
FDP_ACC.2.1 La TSF doit appliquer la politique de contrôle d'accès basé sur les rôles sur
• Sujets :
o Utilisateur S.UME
• Objets :
o O.utilisateur ;
23
o.rôle ;
de O. règle;
o O.réglage.
et toutes les opérations entre les sujets et objets couverts par le SFP.
FDP_ACC.2.2 La TSF doit s'assurer que toutes les opérations entre tout sujet contrôlé par la TSF
et tout objet contrôlé par la TSF sont couvertes par une SFP de contrôle d'accès.
5.3.1.16 FDP_ACF.1/UME Contrôle d'accès basé sur les attributs de sécurité
FDP_ACF.1.1 La TSF doit appliquer la politique de contrôle d'accès basé sur les rôles aux objets
sur la base des éléments suivants :
• Sujets : o
Utilisateur S.UME, avec attributs de sécurité :
User.rolesList ;
Utilisateur.rule ;
Utilisateur.isLocked ;
Utilisateur.isEnable ;
• Objets :
o O.utilisateur ;
du rôle O.
de O. règle;
o O.réglage.
FDP_ACF.1.2/ La TSF doit appliquer les règles suivantes pour déterminer si une
opération entre sujets contrôlés et objets contrôlés est autorisée :
• L'utilisateur S.UME est autorisé à effectuer toutes les opérations définies dans FMT_SMF.1.1/
UME, si et seulement si l'utilisateur est authentifié et que sa User.rolesList inclut la
valeur : Administrateur de sécurité ;
o L'utilisateur S.UME est autorisé à exécuter OP.logReview, si l'utilisateur est authentifié et que
sa User.rolesList inclut un rôle disposant du droit d'affichage du journal.
FDP_ACF.1.3 La TSF doit autoriser explicitement l'accès des sujets aux objets sur la base
des règles supplémentaires suivantes : Aucune.
FDP_ACF.1.4 La TSF doit explicitement refuser l'accès des sujets aux objets sur la base des règles
supplémentaires suivantes :
• L'utilisateur S.UME est verrouillé (User.isLocked est True) ;
• L'utilisateur S.UME n'est pas activé (User.isEnable est False) ;
• L'utilisateur S.UME n'a aucun rôle attribué (User.rolesList est vide) ;
• Le mot de passe de l'utilisateur S.UME a expiré (heure actuelle >=
User.rule.passwordExpirationDate) ;
• L'adresse IP source de l'utilisateur S.UME n'est pas autorisée (non incluse dans
User.rule.allowedIPs);
• La session utilisateur S.UME a été interrompue en raison de :
o Inactivité (Setting.idleTimeout) ;
o Son rôle est en cours d'édition par un administrateur de sécurité (User.rolesList).
• L'opération est effectuée en dehors des horaires autorisés de
Utilisateur S.UME (User.rule.allowedWorkSchedule) ;
• L'administrateur de sécurité Role.type est verrouillé.
24
5.3.1.17 FMT_MSA.1/UME Gestion des attributs de sécurité
FMT_MSA.1.1 La TSF doit appliquer la politique de contrôle d'accès UME pour restreindre la possibilité
de changer_default et de modifier, supprimer les attributs de sécurité :
• Rule.passwordExpirationDate
• Rule.passwordHistoryNumber
• Règle.allowedIPs
• Rule.allowedWorkSchedule
• Règle.authenticationAttempts
• Règle.lockedPeriod
• Définition de .idleTimeout
• Utilisateur.nom d'utilisateur
• Utilisateur.mot de passe
• Utilisateur.passwordHistory
• User.rolesList
• Utilisateur.rule
• Utilisateur.isLocked
• Utilisateur.isEnable
• Type.de rôle
• Rôle.islocked
à l'administrateur de la sécurité.
5.3.1.18 FMT_MSA.3/UME Static attribute initialisation
FMT_MSA.3.1 La TSF doit appliquer la politique de contrôle d'accès UME pour fournir des valeurs par
défaut restrictives pour les attributs de sécurité qui sont utilisés pour appliquer le SFP.
FMT_MSA.3.2 La TSF doit permettre à l' administrateur de sécurité de spécifier des valeurs
initiales alternatives pour remplacer les valeurs par défaut lorsqu'un objet ou une information
est créé.
5.3.2 Exigences fonctionnelles de sécurité pour le BBU
5.3.2.1 FIA_UID.2/BBU Identification de l'utilisateur avant toute action
FIA_UID.2.1 La TSF doit exiger que chaque utilisateur de S.BBU soit identifié avec succès avant
5.3.2.2 FIA_UAU.2/BBU Authentification de l'utilisateur avant toute action
FIA_UAU.2.1 La TSF doit exiger que chaque utilisateur S.BBU soit authentifié avec succès avant
5.3.2.3 FIA_SOS.1/BBU Vérification des secrets
FIA_SOS.1.1 La TSF doit fournir un mécanisme pour vérifier que User.password
rencontrer:
25
• La plage de longueur minimale du mot de passe est de 6 à 20 et la valeur recommandée par défaut
est de 12. comprenant quatre types : chiffre, lettre majuscule, lettre minuscule, autres caractères ;
• Le nouveau mot de passe ne peut pas être identique à l'un des derniers mots de
passe (Rule.passwordHistoryNumber) définis dans
User.passwordHistory.
5.3.2.4 Gestion des échecs d'authentification FIA_AFL.1/BBU
FIA_AFL.1.1 La TSF doit détecter lorsqu'un entier positif configurable par l'administrateur
(User.Rule.authenticationAttempts) compris entre 1 et 6 (par défaut 6), des tentatives d'authentification
infructueuses liées à l'authentification de l'utilisateur S.BBU se produisent.
FIA_AFL.1.2 Lorsque le nombre défini de tentatives d'authentification infructueuses est atteint, la TSF
verrouille le compte utilisateur S.BBU.
• Jusqu'à ce qu'il soit déverrouillé par l'administrateur, ou
• Jusqu'à ce qu'un délai configurable par l'administrateur (Rule.lockedPeriod) soit écoulé, si le compte
n'a pas été défini sur un verrouillage permanent.
5.3.2.5 FTA_MCS.1/BBU Limitation de base sur plusieurs sessions simultanées
FTA_MCS.1.1 La TSF doit limiter le nombre maximum de sessions simultanées
appartenant au même utilisateur S.BBU.
FTA_MCS.1.2 La TSF imposera, par défaut, une limite de 5 sessions par utilisateur.
Note d'application : Le nombre maximum de sessions utilisateur simultanées est de 20.
5.3.2.6 Terminaison initiée par FTA_SSL.3/BBU TSF
FTA_SSL.3.1 La TSF doit mettre fin à une session interactive après une période d'inactivité égale au
temps configuré (Setting.idleTimeout).
5.3.2.7 FAU_GEN.1/BBU Génération de données d'audit
FAU_GEN.1.1 La BBU doit être capable de générer un enregistrement d'audit des événements auditables
suivants :
a) Démarrage et arrêt des fonctions d'audit ;
b) Tous les événements auditables pour le niveau d'audit non spécifié ; et
c) Les événements auditables suivants :
• Authentification des utilisateurs S.BBU (journal de sécurité) ;
• OP.lockUnlockUser (journal de sécurité) ;
• OP.userManagement (journal des opérations) ;
• OP.idleTimeout (journal des opérations).
FAU_GEN.1.2 La TSF doit enregistrer dans chaque enregistrement d'audit au moins les informations
suivantes :
a) Date et heure de l'événement, type d'événement, identité du sujet (le cas échéant) et résultat (succès
ou échec) de l'événement ; et
b) Pour chaque type d'événement d'audit, sur la base des définitions d'événements auditables du
composants fonctionnels inclus dans le PP/ST, aucun.
26
Note d'application : Le démarrage et l'arrêt des fonctions d'audit ne sont pas explicitement enregistrés,
cependant la fonctionnalité de journalisation est activée au démarrage et ne peut pas être désactivée.
5.3.2.8 FAU_STG.1/BBU Stockage protégé de la piste d'audit
FAU_STG.1.1 La TSF doit protéger les enregistrements d'audit stockés dans la piste d'audit contre toute
suppression non autorisée.
FAU_STG.1.2 La TSF doit être capable d' empêcher les modifications non autorisées des enregistrements
d'audit stockés dans la piste d'audit.
5.3.2.9 FAU_STG.4/BBU Prévention de la perte de données d'audit
FAU_STG.4.1 La TSF doit écraser les enregistrements d'audit stockés les plus anciens3 si le
la piste d'audit est pleine.
Note d'application : les enregistrements d'audit peuvent être exportés vers un serveur de sauvegarde.
5.3.2.10 FTP_ITC.1/BBUSEG Canal de confiance interTSF
FTP_ITC.1.1 La BBU doit fournir un canal de communication entre ellemême et SEG qui est logiquement
distinct des autres canaux de communication et assure l'identification assurée de ses points d'extrémité
et la protection des données du canal contre toute modification ou divulgation.
FTP_ITC.1.2 La BBU doit permettre à la BBU et au SEG d'initier la communication via le canal de
confiance.
FTP_ITC.1.3 La BBU doit initier la communication via le canal de confiance pour la transmission des
données utilisateur.
5.3.2.11 FTP_ITC.1/BBUBBU Canal de confiance interTSF
FTP_ITC.1.1 La BBU doit fournir un canal de communication entre ellemême et une autre BBU qui est
logiquement distinct des autres canaux de communication et qui assure l'identification de ses points
d'extrémité et la protection des données du canal contre toute modification ou divulgation.
FTP_ITC.1.2 La BBU doit permettre à la BBU et à l'autre BBU d'initier la communication via le canal de
confiance.
FTP_ITC.1.3 La BBU doit initier la communication via le canal de confiance pour la transmission des
5.3.2.12 Canal de confiance FTP_ITC.1/BBUUE InterTSF
FTP_ITC.1.1 La TSF doit fournir un canal de communication entre ellemême et l'UE qui est logiquement
distinct des autres canaux de communication et fournit
3 L'opération a été réalisée pour « ne prendre aucune autre mesure », et cela a ensuite été
affiné pour rendre la phrase plus lisible.
27
identification assurée de ses points finaux et protection des données du canal contre la modification
ou la divulgation.
FTP_ITC.1.2 La TSF doit permettre à la TSF et à l'UE d'initier une communication via le canal de
confiance.
FTP_ITC.1.3 La TSF doit initier la communication via le canal de confiance pour la transmission des
Note d'application : Ce SFR est appliqué par défaut par la BBU. Cependant, la spécification 3GPP
[TS33501] exige que la BBU autorise les connexions non cryptées depuis l'UE.
5.3.2.13 FIA_ATD.1/BBU Définition de l'attribut utilisateur
FIA_ATD.1.1 La TSF doit maintenir la liste suivante d'attributs de sécurité appartenant à un utilisateur
S.BBU individuel :
• Utilisateur.nom d'utilisateur ;
• Utilisateur.mot de passe ;
• User.rolesList ;
• Utilisateur.isLocked ;
• Utilisateur.isEnable ;
• Utilisateur.passwordHistory ;
• Utilisateur.rule.allowedIPs ;
• User.rule.passwordHistoryNumber ;
• User.rule.authenticationAttempts ;
• User.Rule.lockedPeriod ;
5.3.2.14 FMT_SMR.1/BBU Rôle de sécurité
FMT_SMR.1.1 La TSF doit maintenir les rôles :
l' administrateur
o Entretien
oOrdinaire _
FMT_SMR.1.2 La TSF doit pouvoir associer des utilisateurs à des rôles.
5.3.2.15 FMT_SMF.1/BBU Spécification des fonctions de gestion
FMT_SMF.1.1 La TSF doit être capable d'exécuter les fonctions de gestion suivantes : Fonction de
gestion
OP.ruleManagement > Relatif à SFR
User.Rule.allowedIPs FDP_ACF.1/BBU
Définissez si un utilisateur (à qui la règle est attribuée) ne peut se connecter
qu'à partir de certaines adresses IP, et si oui, quelles adresses IP.
OP.idleTimeout > Setting.idleTimeout FTA_SSL.3/BBU
Définissez la durée pendant laquelle les utilisateurs peuvent rester connectés lorsqu'ils sont inactifs.
OP.ruleManagement > FDP_ACF.1/BBU
User.Rule.passwordExpirationDate
Définir si le mot de passe d'un utilisateur (attribué à la règle) expire
après un certain temps et, si oui, après combien de temps
OP.ruleManagement > Rule.passwordHistoryNumber FIA_SOS.1/BBU
28
Définissez la longueur de l'historique des mots de passe conservé pour
empêcher les utilisateurs d'utiliser le même mot de passe. Par exemple, s'il est
défini sur 3, les utilisateurs ne peuvent pas utiliser les 3 derniers mots de passe.
OP.ruleManagement > FIA_AFL.1/BBU
User.Rule.authenticationAttempts Définir le
nombre de tentatives d'authentification infructueuses autorisées
OP.ruleManagement > User.Rule.lockedPeriod Définir la FIA_AFL.1/BBU
durée pendant laquelle un compte (attribué à la règle) reste verrouillé
OP.lockUnlockUser > User.isLocked Déverrouiller FIA_AFL.1/BBU
un utilisateur compte
OP.userManagement Créer, FIA_ATD.1/BBU
modifier et supprimer des comptes d'utilisateurs FIA_SOS.1/BBU
OP.enableDisableUser FIA_ATD.1/BBU
Désactiver/activer les comptes
d'utilisateurs OP.userManagement > User.rolesList FMT_SMR.1/BBU
Ajouter ou supprimer des rôles vers/des utilisateurs
5.3.2.16 FDP_ACC.2/BBU Contrôle d'accès complet
FDP_ACC.2.1 La TSF devra appliquer la Politique de Contrôle d'Accès BBU sur : Sujets : •
S.BBU.
Objets : •
O.user ; •
O.rôle ; •
O.règle ; •
O.Réglage. et
toutes les opérations entre les sujets et objets couverts par le SFP.
FDP_ACC.2.2 La TSF doit s'assurer que toutes les opérations entre tout sujet contrôlé par la
TSF et tout objet contrôlé par la TSF sont couvertes par une SFP de contrôle d'accès.
5.3.2.17 FDP_ACF.1/BBU Contrôle d'accès basé sur les attributs de sécurité
FDP_ACF.1.1 La TSF doit appliquer la politique de contrôle d'accès basée sur les rôles aux objets
sur la base des éléments suivants : •
Sujets : o
utilisateur S.BBU, avec des attributs de sécurité :
User.rolesList ;
Utilisateur.isLocked ;
Utilisateur.isEnable ;
User.rule.passwordExpirationDate ; Rôle.type ;
• Objets : o
O.user ; o
O.rôle.
FDP_ACF.1.2 La TSF doit appliquer les règles suivantes pour déterminer si une opération
entre sujets contrôlés et objets contrôlés est autorisée :
29
• L'utilisateur S.BBU est autorisé à effectuer toutes les opérations définies dans
FMT_SMF.1.1/BBU si et seulement si l'utilisateur est authentifié et que sa User.rolesList
inclut la valeur : Administrateur ;
FDP_ACF.1.3 La TSF doit autoriser explicitement l'accès des sujets aux objets sur la
base des règles supplémentaires suivantes : Aucune.
FDP_ACF.1.4 La TSF doit explicitement refuser l'accès des sujets aux objets sur la base des
règles supplémentaires suivantes :
• L'utilisateur S.BBU est verrouillé (User.isLocked est True) ;
• L'utilisateur S.BBU n'est pas activé (User.isEnable est False)
• L'utilisateur S.BBU n'a aucun rôle attribué (User.rolesList est vide) ;
• La session utilisateur S.BBU a été interrompue pour cause d'inactivité.
(Paramètre.idleTimeout);
• L'adresse IP source de l'utilisateur S.BBU n'est pas autorisée (non incluse dans
User.rule.allowedIPs);
• Le mot de passe de l'utilisateur S.BBU a expiré (heure actuelle >=
User.rule.passwordExpirationDate);
• L'administrateur Role.type est verrouillé.
5.3.2.18 FMT_MSA.1/BBU Gestion des attributs de sécurité
FMT_MSA.1.1 La TSF doit appliquer la politique de contrôle d'accès BBU pour restreindre la
possibilité de changer_default et de modifier les attributs de sécurité :
• Rule.passwordExpirationDate
• Rule.passwordHistoryNumber
• Règle.allowedIPs
• Règle.authenticationAttempts
• Règle.lockedPeriod
• Définition de .idleTimeout
• Utilisateur.nom d'utilisateur
• Utilisateur.mot de passe
• User.rolesList
• Utilisateur.rule
• Utilisateur.isLocked
• Utilisateur.isEnable
• Type.de rôle
• Rôle.islocked
à l'Administrateur.
5.3.2.19 FMT_MSA.3/BBU Static attribute initialisation
FMT_MSA.3.1 La TSF doit appliquer la politique de contrôle d'accès BBU pour fournir des
valeurs par défaut permissives pour les attributs de sécurité qui sont utilisés pour appliquer le SFP.
FMT_MSA.3.2 La TSF doit permettre à l' administrateur de spécifier des valeurs initiales
alternatives pour remplacer les valeurs par défaut lorsqu'un objet ou une information est créé.
30
5.4 Exigences en matière d'assurance de sécurité
Les exigences d'assurance sont EAL3+ ALC_FLR.2 et ont été résumées dans le tableau suivant :
Composants d'assurance
Classe d'assurance
Identifiant Nom
ADV_ARC.1 Description de l'architecture de sécurité
Spécification fonctionnelle avec
ADV : Développement ADV_FSP.3
résumé complet
ADV_TDS.2 Conception architecturale
Conseils AGD_OPE.1 Guide utilisateur opérationnel
AGD : documents
AGD_PRE.1 Procédures préparatoires
ALC_CMC.3 Contrôles d'autorisation
Représentation de la mise en œuvre
ALC_CMS.3
Couverture CM
ALC_DEL.1 Modalités de livraison
ALC : prise en charge du cycle de vie
ALC_FLR.2 Procédures de signalement des défauts
Identification de la sécurité
ALC_DVS.1 mesures
Cycle de vie défini par le développeur
ALC_LCD.1 modèle
ASE_CCL.1 Déclarations de conformité
ASE_ECD.1 Définition étendue des composants
ASE_INT.1 Présentation de ST
ASE : cible de sécurité
ASE_OBJ.2 Objectifs de sécurité
évaluation
ASE_REQ.2 Exigences de sécurité dérivées
ASE_SPD.1 Définition du problème de sécurité
Spécification récapitulative de la TOE ASE_TSS.1
ATE_COV.2 Analyse de couverture
Test ATE_DPT.1 : conception de base
ATE : essais
ATE_FUN.1 Tests fonctionnels
ATE_IND.2 Tests indépendants échantillon
AVA : vulnérabilité
évaluation AVA_VAN.2 Analyse de vulnérabilité
31
5.5 Justification des exigences en matière d'assurance de la sécurité
Les exigences d'assurance de sécurité pour cette cible de sécurité sont EAL3+ALC_FLR.2.
Les raisons de ce choix sont les suivantes :
EAL 3 est réputé offrir un bon équilibre entre assurance et
coûts et est conforme aux exigences des clients de ZTE.
ALC_FLR.2 garantit que ZTE dispose d'un processus clair et fonctionnel pour
accepter les failles de sécurité des utilisateurs et mettre à jour la TOE si
nécessaire. Ceci est également conforme aux exigences des clients de ZTE.
32
6 Spécification sommaire de la TOE
Ce chapitre décrit comment la TOE met en œuvre les exigences fonctionnelles de sécurité définies au chapitre
5. La description couvre à la fois les SFR UME et BBU, sauf indication contraire explicite.
6.1 Identification et authentification des utilisateurs
Les utilisateurs de la TOE doivent s'identifier et s'authentifier avant de pouvoir effectuer toute action à l'aide de la
TOE. L'authentification des utilisateurs est basée sur le nom d'utilisateur et le mot de passe fournis par les
utilisateurs et comporte un nombre limité de tentatives avant que le compte utilisateur ne soit verrouillé. Les
utilisateurs peuvent être déverrouillés par l'administrateur de sécurité dans l'UME et par l'administrateur dans le
BBU. Les utilisateurs peuvent également attendre d'être automatiquement déverrouillés après une période de
temps configurable par l'administrateur de sécurité dans l'UME et par l'administrateur dans la BBU.
La TOE conserve les informations utilisateur afin d'appliquer l'authentification et le contrôle d'accès. Les
informations suivantes sont conservées pour chaque utilisateur :
• Nom d'utilisateur et mot de passe ;
• Historique des mots de passe ;
• Liste des rôles d'utilisateur ;
• Règles d'utilisation, y compris la date d'expiration, la durée de l'historique des mots de passe, les adresses IP
autorisées, le temps d'authentification autorisé, le nombre de tentatives d'authentification et la période de
verrouillage ;
• Indicateurs d'état verrouillés et activés.
Les sessions utilisateur simultanées sont limitées à un maximum de 1 pour chaque utilisateur de l'UME et de 5
pour chaque utilisateur de la BBU par défaut (avec 20 comme valeur configurable maximale). De plus, les
sessions se terminent automatiquement après une période d'inactivité configurable par l'administrateur de
sécurité dans l'UME et par l'administrateur dans la BBU. Une session utilisateur se termine également
automatiquement dans l'UME lorsque l'administrateur de sécurité modifie les rôles utilisateur.
L'authentification de l'utilisateur peut être restreinte en fonction de l'adresse IP source de l'utilisateur. Le
L'administrateur peut définir une adresse IP autorisée (ou un ensemble d'adresses IP) afin que l'utilisateur ne
puisse être authentifié avec succès qu'en se connectant à partir de l'adresse IP autorisée. L'administrateur de
sécurité UME peut également limiter la durée pendant laquelle un utilisateur peut être authentifié dans le
UME en définissant une période de temps autorisée sur la configuration UME.
Les mots de passe des utilisateurs doivent respecter certaines règles pour garantir qu'ils ne peuvent pas être
facilement devinés ou brisés par la force brute :
• (Uniquement dans l'UME) Au moins 8 caractères dont quatre types : chiffre, majuscule
lettre majuscule, lettre minuscule, autres caractères ;
• (Uniquement dans le BBU) La plage de longueur minimale du mot de passe est de 6 à 20 et la valeur
recommandée par défaut est de 12. comprenant quatre types : chiffre, lettre majuscule, lettre
minuscule, autres caractères ;
33
• (Uniquement dans l'UME) Ne peut pas être identique au nom d'utilisateur, au nom d'utilisateur
inversé ou à un mot de passe commun du dictionnaire ;
• Le nouveau mot de passe ne peut pas être identique à l'un des derniers mots de passe
(Rule.passwordHistoryNumber) définis dans User.passwordHistory.
Les mots de passe qui ne respectent pas ces règles sont rejetés par la TOE.
FIA_UID.2, FIA_UAU.2, FIA_AFL.1, FIA_ATD.1, FTA_MCS.1, FIA_SOS.1 et FTA_SSL.3.
6.2 Contrôle d'accès
La TOE applique le contrôle d'accès aux utilisateurs en fonction des rôles d'utilisateur. Chaque rôle
d'utilisateur dispose d'un ensemble d'actions autorisées (y compris diverses actions de gestion). Un
utilisateur peut avoir plus d'un rôle, l'accès utilisateur est donc la combinaison de tous ses
les rôles.
Le tableau suivant identifie l'action autorisée pour chaque rôle dans l'UME :
Rôle Actions autorisées
Administrateur de sécurité Opérations de gestion de la sécurité (telles que définies dans FMT_SMF.1/
UME)
Examen du journal de tous les utilisateurs.
Administrateur Toutes les opérations (inclure tous les examens des journaux de l'utilisateur), à
l'exception des opérations de gestion de la sécurité.
Entretien Tous (y compris l'autoexamen des journaux) à l'exception des
opérations de gestion de la sécurité et des opérations de gestion du
système.
Opérateur Opérations de maintenance normales (y compris l'autoexamen des
journaux) à l'exception des opérations de gestion de la sécurité.
Superviseur Afficher les opérations (y compris l'examen automatique des journaux), à l'exception
des opérations de gestion de la sécurité.
Le tableau suivant identifie l'action autorisée pour chaque rôle/groupe dans le BBU :
Rôle/Groupe Actions autorisées
Administrateur Opérations de gestion de la sécurité (telles que définies dans
FMT_SMF.1/BBU)
Entretien Autorisation en lecture seule pour les données du nœud de gestion de la
sécurité, et autorisations de lecture, d'écriture et d'exécution pour les autres
données du nœud
Ordinaire Ne disposez d'aucune autorisation de lecture, d'écriture ou d'exécution pour
les données du nœud de gestion de la sécurité et disposez d'une autorisation
en lecture seule pour les autres nœuds.
34
Le contrôle d'accès vérifie également que les informations utilisateur sont correctes, par exemple que l'utilisateur est
activé et non verrouillé, que l'utilisateur n'est pas inactif, que l'adresse IP de l'utilisateur est autorisée, que le mot de
passe de l'utilisateur n'a pas expiré et que le rôle de l'utilisateur n'est pas verrouillé. Le contrôle d'accès sur l'UME
vérifie également l'intervalle de temps autorisé de l'utilisateur et si le rôle de l'utilisateur est en cours de modification
par l'administrateur de sécurité.
FMT_SMR.1, FDP_ACC.2, FDP_ACF.1, FMT_SMF.1, FMT_MSA.1 et FMT_MSA.3
6.3 Audit
La TOE génère des journaux d'audit pour enregistrer les événements suivants :
• Authentification des utilisateurs ;
• Verrouillage ou déverrouillage d'un compte utilisateur ;
• Activation ou désactivation d'un compte utilisateur (uniquement UME) ;
• Ajouter, supprimer ou modifier un compte utilisateur ;
• Ajouter, supprimer ou modifier un rôle (uniquement UME);
• Ajouter, supprimer ou modifier la règle d'un utilisateur (uniquement UME);
• Lorsqu'une session utilisateur se termine par un délai d'attente ;
Les enregistrements du journal incluent la date et l'heure de l'événement, l'identité du sujet (le cas échéant) et le
résultat (succès ou échec) de l'événement.
La TOE offre la possibilité de consulter les journaux à l'administrateur de sécurité de l'UME.
Le magasin d'audit est protégé contre les manipulations. Les enregistrements du journal ne peuvent pas être modifiés
et ne peuvent être supprimés que par l'administrateur de l'UME et par l'administrateur du BBU si les enregistrements
datent de 30 jours ou plus.
Les enregistrements du journal s'écrasent lorsque la trace du journal est pleine dans l'UME.
Néanmoins, les enregistrements peuvent être automatiquement envoyés à un serveur distant installé sur le réseau
de gestion de l'UME.
FAU_GEN.1, FAU_SAR.1, FAU_STG.1 et FAU_STG.4
6.4 Communication sécurisée
La TOE assure une interaction sécurisée entre ses différentes parties et entre ellemême et les différentes machines
de l'environnement, de sorte que les données utilisateur et/ou les commandes de gestion ne puissent pas être lues
ou modifiées entretemps.
La communication entre l'UME et le client UME est protégée par HTTPS.
La connexion entre le BBU et le SEG est protégée par IPSEC.
35
La connexion entre la BBU et une autre BBU est protégée par IPSEC.
La connexion entre la TOE et l'UE est protégée par un algorithme de chiffrement.
Algorithmes de sécurité des tables dans différents canaux
Canal Algorithmes de technologie de sécurité Longueur de la clé
Client UMEUME HTTPS ECDHERSAAES256GCMSHA384 ;

ANDRSAAES256GCMSHA384 ;
ECDHERSAAES128GCMSHA256 ;
ANDRSAAES128GCMSHA256.
BBUSEG&BBUBBU IPSEC aes128cbc, Aes : 128 192 256

aes192cbc, 3déc:192
aes256cbc,
3descbc,
TOEUE Sécurité radio NULL, Snow3G, AES, ZUC 128 bits
FTP_ITC.1 et FTP_TRP.1
36
7 Justifications
7.1 Justification des objectifs de sécurité
Hypothèses/Menaces Objectifs
T.COMMUNICATION_CH Ce fil est directement couvert par
O.SECURE_COMUNICATION car il impose d'utiliser
canaux de communication sécurisés sur toutes les communications
entre:
1. L'abonné (UE) et la BBU ;
2. Une BBU et une autre BBU ;
3. Une BBU et la passerelle de confiance du réseau central ;
4. L'UME et le client UME.
T.UNAUTHENTICATE_USER Ce fil est directement couvert par
O.USER_AUTHENTICATION car il applique l'authentification
des utilisateurs sur les composants BBU et UME.
T.UNAUTHORIZED_ADMIN Ce fil est directement couvert par
O.USER_AUTHENTICATION et
O.ACCESS_CONTROL car ceuxci appliquent l'utilisateur
authentification et autorisation basées sur les informations de l'utilisateur
rôle.
T.UNDETECTED_ACTIVITY Ce fil est directement couvert par
O.USER_AUTHENTICATION et O.AUDITING car ils appliquent
l'authentification et la journalisation de l'utilisateur
actions sur le BBU et l’UME.
A.TIME Cette hypothèse est confirmée par OE.TIME, qui couvre
directement l'hypothèse.
A.UME_TRUSTED_NETWORK Cette hypothèse est confirmée par
OE.UME_TRUSTED_NETWORK, qui couvre directement
l'hypothèse.
A.PROTECTION_PHYSIQUE Cette hypothèse est confirmée par
OE.PHYSICAL_PROTECTION, qui couvre directement
l'hypothèse.
A. ADMINISTRATEURS Cette hypothèse est confirmée par OE.ADMINISTRATERS, qui
couvre directement l'hypothèse.
A.UME_PLATFORME Cette hypothèse est confirmée par OE.UME_PLATFORM, qui
couvre directement l'hypothèse.
A.UME_CLIENT Cette hypothèse est confirmée par OE.UME_CLIENT, qui couvre
directement l'hypothèse.
37
7.2 Justification des exigences fonctionnelles de sécurité
Objectifs de sécurité Des SFR répondant aux objectifs de sécurité
O.SECURE_COMUNICATION Cet objectif est atteint par :
• FTP_TRP.1/UMEClient pour la sécurité
communication entre l'UME et le client ;
• FTP_ITC.1/BBUSEG pour la communication
sécurisée entre la BBU et le serveur sécurisé
passerelle;
• FTP_ITC.1/BBUBBU pour la sécurité
communication entre la BBU et une autre
BBU ;
• FTP_ITC.1/BBUUE pour la communication
sécurisée entre la BBU et l'UE.
O.USER_AUTHENTICATION Cet objectif est atteint par :
• Identification et authentification de l'utilisateur avant toute action
(FIA_UID.2/UME, FIA_UID.2/BBU, FIA_UAU.2/UME
et FIA_UAU.2/BBU) ;
• Tentatives d'authentification utilisateur limitées
(FIA_AFL.1/UME et FIA_AFL.1/BBU) ;
• Mot de passe utilisateur complexe (FIA_SOS.1/UME et
FIA_SOS.1/BBU) ;
• Limitation de session utilisateur (FTA_SSL.3/UME,
FTA_SSL.3/BBU, FTA_MCS.1/UME et FTA_MCS.1/
BBU) ;
• Prise en charge de la configuration utilisateur (FMT_SMF.1/UME
et FMT_SMF.1/BBU).
O.ACCESS_CONTROL Cet objectif est atteint par :
• Implémentation des rôles et attributs des utilisateurs
(FIA_ATD.1/UME, FIA_ATD.1/BBU,
FMT_SMR.1/UME et FMT_SMR.1/UME) ;
• Application du contrôle d'accès basé sur les rôles et attributs
des utilisateurs (FDP_ACC.2/UME, FDP_ACC.2/BBU,
FDP_ACF.1/UME, FDP_ACF.1/BBU, FMT_MSA.1/
UME, FMT_MSA.1/BBU, FMT_MSA.3 /UME et
FMT_MSA.3/BBU);
• Prise en charge de la configuration du contrôle d'accès
(FMT_SMF.1/UME et FMT_SMF.1/BBU).
O.AUDIT Cet objectif est atteint par :
• Génération de données d'audit (FAU_GEN.1/UME et
FAU_GEN.1/BBU) ;
• Audit de la protection des données (FAU_STG.1/
UME, FAU_STG.1/BBU, FAU_STG.4/UME,
FAU_STG.4/BBU) ;
• Soutenir l'examen des données d'audit (FAU_SAR.1/UME,
38
Objectifs de sécurité Des SFR répondant aux objectifs de sécurité
FMT_SMF.1/UME et FMT_SMF.1/BBU).
39
7.3 Dépendances
SFR Dépendance Couverture
FIA_UID.2/UME Aucun. Aucun.
FIA_UAU.2/UME FIA_UID.1 FIA_UID.2/UME

FIA_AFL.1/UME FIA_UAU.1 FIA_UAU.1/UME
FIA_SOS.1/UME Aucun. Aucun.
FTA_SSL.3/UME Aucun. Aucun.
FTA_MCS.1/UME FIA_UID.1 FIA_UID.2/UME

FAU_GEN.1/UME FPT_STM.1 N/A Voir cidessous
FAU_SAR.1/UME FAU_GEN.1 FAU_GEN.1/UME

FAU_STG.1/UME FAU_GEN.1 FAU_GEN.1/UME
FAU_STG.4/UME FAU_GEN.1 FAU_GEN.1/UME
FTP_TRP.1/UMEClient Aucun. Aucun.
FIA_ATD.1/UME Aucun. Aucun.
FMT_SMF.1/UME Aucun. Aucun.
FMT_SMR.1/UME FIA_UID.1 FIA_UID.2/UME

FDP_ACC.2/UME FDP_ACF.1 FDP_ACF.1/UME
FDP_ACF.1/UME FDP_ACC.1 FDP_ACC.1/UME
FMT_MSA.3 FMT_MSA.3/UME
FMT_MSA.1/UME FDP_ACC.1 FDP_ACC.2/UME
FMT_SMR.1 FMT_SMR.1/UME
FMT_SMF.1 FMT_SMF.1/UME
FMT_MSA.3/UME FMT_MSA.1 FMT_MSA.1/UME
FMT_SMR.1 FMT_SMR.1/UME
FIA_UID.2/BBU FIA_UID.1 FIA_UID.2/BBU
FIA_UAU.2/BBU FIA_UAU.1 FIA_UAU.1/BBU
FIA_SOS.1/BBU Aucun. Aucun.
FIA_AFL.1/BBU FIA_UAU.1 FIA_UAU.1/BBU

FTA_MCS.1/BBU FIA_UID.1 FIA_UID.2/BBU
FTA_SSL.3/BBU Aucun. Aucun.
FAU_GEN.1/BBU FPT_STM.1 N/A Voir cidessous
FAU_STG.1/BBU FAU_GEN.1 FAU_GEN.1/BBU

FAU_STG.4/BBU FAU_GEN.1 FAU_GEN.1/BBU
FTP_ITC.1/BBU SEG Aucun. Aucun.
FTP_ITC.1/BBUBBU Aucun. Aucun.
FTP_ITC.1/BBUUE Aucun. Aucun.
FIA_ATD.1/BBU Aucun. Aucun.
FMT_SMF.1/BBU Aucun. Aucun.
FMT_SMR.1/BBU FIA_UID.1 FIA_UID.2/BBU

FDP_ACC.2/BBU FDP_ACF.1 FDP_ACF.1/BBU
FDP_ACF.1/BBU FDP_ACC.1 FDP_ACC.1/BBU
FMT_MSA.3 FMT_MSA.3/BBU
FMT_MSA.1/BBU FDP_ACC.1 FDP_ACC.2/BBU
40
FMT_SMR.1 FMT_SMR.1/BBU
FMT_SMF.1 FMT_SMF.1/BBU
FMT_MSA.3/BBU FMT_MSA.1 FMT_MSA.1/BBU
FMT_SMR.1 FMT_SMR.1/BBU
FPT_STM.1 ne peut pas être implémenté par la TOE car il n'a pas la capacité de générer des
horodatages fiables. Les informations temporelles sont donc fournies par un serveur NTP dans le
réseau de la TOE (OE.TIME).
41
A Abréviations
CA Courant alternatif
BBU unité de bande de base
BPL Module de traitement en bande de base
CC Module de contrôle et d'horloge
CC Courant continu
SME Système de gestion des éléments
PSE Système de paquets évolué
eNoeud B Nœud évolué B
HALEINE Expert en gestion unifiée
gNœud B génération Nœud B
COURU Nouvelle Génération Réseau d'Accès Radio
MAIS Module de réseau de ventilateurs
PI protocole Internet
IPSEC Protocole Internet sécurisé
Non. Nouvelle génération
DIRIGÉ Diode électroluminescente
LTE évolution à long terme
L3 Couche 3
MAMAN Entité de gestion de la mobilité
MAC Contrôle d'accès au support
DANS LE Strate de nonaccès
NTP Protocole de temps réseau
PDCP Protocole de convergence de données par paquets
PHY Couche physique
MP Module de puissance
RF Fréquence radio
RLC Contrôle de liaison radio
RRU Unité radio à distance
sur Tableau d'alarme de chantier
SE Carte d'extension d'alarme de site
SGW Passerelle de service
AMF Fonction de gestion des accès et de la mobilité
FPU Fonction du port utilisateur
DIRE Passerelle de sécurité
UE Équipement utilisateur
UMTS Système universel de télécommunications mobiles
42
Références B
[CCp1] Critères communs pour l'évaluation de la sécurité des technologies de
l'information, partie 1 : introduction et modèle général, version 3.1, révision
5, avril 2017.
l'information, partie 2 : composants fonctionnels de sécurité, version 3.1,
révision 5, avril 2017.
l'information, partie 3 : composants d'assurance de sécurité, version 3.1,
révision 5, avril 2017.
[CEMe] Méthodologie commune d'évaluation de la sécurité des technologies de
l'information Méthodologie d'évaluation, version 3.1 Révision 5, avril 2017.
[TS33501] 3GPP TS33.501 Architecture et procédures de sécurité pour le système 5G
43

Nscib CC 0132539 ST

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Nscib CC 0132539 ST

Transféré par

Droits d'auteur :

Formats disponibles

Machine Translated by Google

Version Date Commentaire

0,1 23 octobre 2019 Première version

0,2 16 décembre 2019 Révision générale

0,3 14 janvier 2020 Révision générale appliquant les modifications

0,9 6 août 2020 SPD et objectifs de sécurité ajoutés.

0,13 19 août 2020 Résoudre des problèmes mineurs

0,14 21 août 2020 Corrections mineures et note d'application ajoutées à

0,21 19 janvier 2021 FAU_STG.4/BBU ajouté à la justification des exigences

[UG­BBU­CONF] Gestion de la configuration RAN 1.3 PDF

[UG­BBU­OPE] Gestion des éléments RAN 1.0 PDF

[UG­UME­ACP] Procédure d'acceptation 0,3 PDF

[UG­UME­INS] Guide d'installation et de déploiement d'UME 1.3 PDF

[UG­UME­LE] Événements du journal de sécurité 1.0 PDF

[UG­UME­MML] Liste des commandes UME 1.0 PDF

[UG­UME­PRE] Description des preuves de protection de l'intégrité du logiciel UME 1.0 PDF

[UG­UME­SPM] Manuel des paramètres de sécurité 1.0 PDF

[UG­UME­UPG] Guide de mise à niveau UME 1.12 PDF

Installation matérielle du ZXRAN A9622E S35 5G 1.0 PDF

Installation matérielle de l'unité d'antenne active ZXRAN A9815 5G 1.0 PDF

Installation matérielle de l'unité d'antenne active ZXRAN A9611 S35 5G 1.0 PDF

Installation matérielle de l'unité radio à distance ZXRAN R9105 S26 5G 1.0 PDF

Installation matérielle de l'unité radio à distance ZXRAN R9105 S35 5G 1.0 PDF

Guide d'installation matérielle de l'unité distante macro radio ZXRAN R9212E 1.0 PDF

Installation matérielle de l'unité distante macro radio ZXRAN R9214E 1.0 PDF

Guide d'installation matérielle de l'unité distante macro radio ZXRAN R9222 1.0 PDF

Installation matérielle de l'unité radio à distance macro ZXSDR R8862A 1.0 PDF

Installation matérielle de l'unité distante macro radio ZXSDR R8894E 1.0 PDF

Installation matérielle de l'unité distante macro radio ZXSDR R8894E 1.0 PDF

OP.ruleManagement ­> FDP_ACF.1/UME

Canal Algorithmes de technologie de sécurité Longueur de la clé

Client UME­UME HTTPS ECDHE­RSA­AES256­GCM­SHA384 ;

BBU­SEG&BBU­BBU IPSEC aes128cbc, Aes : 128 192 256

SFR Dépendance Couverture

FIA_UID.2/UME Aucun. Aucun.

FIA_UAU.2/UME FIA_UID.1 FIA_UID.2/UME

FTA_SSL.3/UME Aucun. Aucun.

FTA_MCS.1/UME FIA_UID.1 FIA_UID.2/UME

FAU_SAR.1/UME FAU_GEN.1 FAU_GEN.1/UME

FIA_ATD.1/UME Aucun. Aucun.

FMT_SMF.1/UME Aucun. Aucun.

FMT_SMR.1/UME FIA_UID.1 FIA_UID.2/UME

FIA_AFL.1/BBU FIA_UAU.1 FIA_UAU.1/BBU

FAU_GEN.1/BBU FPT_STM.1 N/A Voir ci­dessous

FAU_STG.1/BBU FAU_GEN.1 FAU_GEN.1/BBU

FTP_ITC.1/BBU­BBU Aucun. Aucun.

FTP_ITC.1/BBU­UE Aucun. Aucun.

FIA_ATD.1/BBU Aucun. Aucun.

FMT_SMF.1/BBU Aucun. Aucun.

FMT_SMR.1/BBU FIA_UID.1 FIA_UID.2/BBU

Vous aimerez peut-être aussi

[UGBBUCONF] Gestion de la configuration RAN 1.3 PDF

[UGBBUOPE] Gestion des éléments RAN 1.0 PDF

[UGUMEACP] Procédure d'acceptation 0,3 PDF

[UGUMEINS] Guide d'installation et de déploiement d'UME 1.3 PDF

[UGUMELE] Événements du journal de sécurité 1.0 PDF

[UGUMEMML] Liste des commandes UME 1.0 PDF

[UGUMEPRE] Description des preuves de protection de l'intégrité du logiciel UME 1.0 PDF

[UGUMESPM] Manuel des paramètres de sécurité 1.0 PDF

[UGUMEUPG] Guide de mise à niveau UME 1.12 PDF

OP.ruleManagement > FDP_ACF.1/UME

Client UMEUME HTTPS ECDHERSAAES256GCMSHA384 ;

BBUSEG&BBUBBU IPSEC aes128cbc, Aes : 128 192 256

FAU_GEN.1/BBU FPT_STM.1 N/A Voir cidessous

FTP_ITC.1/BBUBBU Aucun. Aucun.

FTP_ITC.1/BBUUE Aucun. Aucun.