En quelques mots, si vous fabriquez, importez ou revendez un produit avec des éléments numériques, vous serez sûrement affecté par le CRA et devrez veiller à sa conformité. Cet article vise à éclairer sur : Que prévoit cette réglementation ? Qui est concerné ? Comment assurer la conformité ? 

Qu’est-ce que le CRA et qu’implique-t-il ?   

Pour comprendre la nécessité du CRA, il est crucial de considérer le contexte plus large de la cybersécurité en Europe. Le CRA est une réglementation ambitieuse conçue pour assurer la sécurité des citoyens de l’UE en s’attaquant aux faibles niveaux observés aujourd’hui de cybersécurité des produits avec des éléments numériques, par le biais d’une intervention politique de l’Union européenne. Pour ce faire, des études approfondies axées sur la cybersécurité des produits numériques ont été menées, aboutissant à la proposition d’une législation définissant les obligations pour l’ensemble des acteurs de la chaîne d’approvisionnement des produits, des fabricants aux distributeurs. 

L’implication de Wavestone dans ce processus souligne son engagement à améliorer les normes de cybersécurité. Nous avons participé à une étude exploratoire approfondie commandée par l’UE, en engageant un large éventail de parties prenantes, y compris des autorités nationales, des organes de l’UE, des fabricants de matériel et de logiciels, des associations professionnelles, des organisations de consommateurs, des chercheurs, des universitaires et des professionnels de la cybersécurité. 

Grâce à la position de Wavestone en tant que leader mondial, et particulièrement européen, dans le domaine de la cybersécurité, plusieurs interviews, groupes de discussion et ateliers ont été organisés. Des informations précieuses ont été recueillies auprès d’interlocuteurs variés, offrant une vision complète qui prend en compte les perspectives de toutes les parties prenantes et permettant de poser les bases du développement du CRA. 

Définition et périmètre 

Le CRA est une proposition législative qui définit les obligations des fabricants, importateurs et distributeurs de produits contenant des éléments numériques commercialisés dans l’UE, tous devant porter le marquage CE dans tous les secteurs. Tel que défini dans la réglementation, cela inclut « tout produit logiciel ou matériel ainsi que ses solutions de traitement de données à distance, comprenant des composants pouvant être commercialisés séparément ». L’objectif de cette réglementation est non seulement de sécuriser les produits autonomes, mais aussi d’assurer la sécurité des chaînes de transmission de données et des infrastructures centrales grâce à l’application de cette norme. 

À cette notion de produit s’ajoute une notion de criticité, le CRA distingue donc deux types de produits : les produits avec des éléments numériques et les produits critiques avec des éléments numériques. Comme détaillé ci-dessous dans la partie « Checklist de conformité au CRA », cela influencera la manière dont la conformité pourra être atteinte. 

Quelques exemples de produits avec des éléments numériques incluent les produits de consommation, les smart cities et les logiciels non essentiels. Les produits critiques avec des éléments numériques comprennent, par exemple, les systèmes de contrôle industriel et les pare-feu. La liste détaillée des produits concernés se trouve dans les annexes de la réglementation. 

 Cependant, comme détaillé ci-dessous dans « Un écosystème complexe », le CRA ne s’applique pas universellement, et les produits de certains secteurs spécifiques ne sont pas tenus de se conformer aux exigences. 

Parties prenantes et responsabilités 

Le CRA impacte tout le cycle de vie des produits numériques, depuis le développement par les fabricants, importateurs et distributeurs jusqu’au consommateur final, mais aussi la gestion des vulnérabilités depuis la conception jusqu’à la fin de vie du produit, au travers d’une responsabilité partagée. 

Exigences essentielles  

Comme mentionné précédemment, l’objectif du CRA est de garantir un niveau suffisant de cybersécurité dans les produits contenant des éléments numériques. Pour ce faire, il introduit des exigences essentielles reposant sur trois piliers  

• Sécurité des produits : Assurer que les produits sont conçus, développés et fabriqués pour atteindre des niveaux de cybersécurité appropriés et qu’ils sont exempts de vulnérabilités exploitables connues. 
• Documentation utilisateur : Fournir une documentation pour garantir une utilisation sécurisée, depuis la mise en service jusqu’à la fin de vie du produit. 
• Gestion des vulnérabilités : Identifier et documenter les vulnérabilités, réaliser des tests de sécurité réguliers, et mettre en place une politique de divulgation des vulnérabilités. 

En cas de non-conformité aux exigences essentielles, des sanctions peuvent être appliquées à l’une des trois parties prenantes. Comme pour le RGPD, chaque État membre doit déterminer les sanctions applicables en cas de violation de cette réglementation. Les pénalités sont basées sur le chiffre d’affaires annuel de l’entreprise et la gravité de l’infraction, avec des amendes pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial total pour les violations graves. 

Comment se conformer au CRA ? 

Chronologie du CRA  

Le CRA a été un projet à long terme, avec presque 10 ans entre l’identification du besoin et la mise en application, reflétant la complexité de l’établissement de réglementations de cybersécurité complètes: 

Les entreprises ont jusqu’en 2026 pour se conformer, avec des obligations intermédiaires. Des exigences similaires peuvent être trouvées dans d’autres réglementations, telles que la NIS2, mais contrairement à d’autres réglementations, le CRA ne nécessite pas de transposition nationale. Le CRA a été adopté par le Parlement européen en mars 2024, et il attend un vote du Conseil européen pour devenir une loi. 

Un écosystème complexe 

L’une des principales préoccupations soulevées lors de la préparation était de savoir comment naviguer dans la multitude de réglementations existantes et parvenir à une harmonie réglementaire, en particulier dans les secteurs où les normes de sécurité, de protection de la vie privée et de cybersécurité s’entrecroisent.  

Le CRA vise à favoriser l’interopérabilité en s’alignant sur le cadre général de la sécurité des produits, sur les exigences de la loi sur la cybersécurité pour les produits, processus et services TIC, et sur les normes de marquage CE pour la conformité européenne. 

Pour simplifier la mise en conformité, le CRA inclut des présomptions de conformité avec les réglementations existantes telles que la directive RED, la loi sur l’IA et certaines règles sectorielles.  

Toutefois, le CRA ne s’applique pas de manière universelle ; certains secteurs, tels que le secteur médical, l’aviation et l’automobile, sont déjà régis par des réglementations établies et sont donc exemptés des dispositions de la réglementation. 

 Checklist de conformité au CRA 

La mise en conformité au CRA implique une compréhension approfondie du texte principal du règlement et de ses deux annexes, qui détaillent la liste des produits concernés, les exigences essentielles, les obligations des fabricants, des importateurs et des distributeurs, ainsi que les autorités nationales compétentes et les sanctions.  

Le processus de certification varie en fonction de la criticité du produit : 

• Pour les produits non critiques : une auto-évaluation est nécessaire. 
• Pour les produits critiques : une évaluation par un tiers est nécessaire, ce qui signifie que la conformité du produit au CRA sera évaluée par une entité certifiée. Au moment de la rédaction de cet article, les schémas de certification exacts n’ont pas encore été spécifiés, mais en France, la certification CESTI est en discussion. 

Cinq points de contrôle principaux doivent être pris en compte pour assurer la conformité :   

1. Analyse d’écarts législatifs : Identifier les écarts entre les pratiques actuelles et les exigences du CRA en examinant les politiques, les processus et les contrôles existants en matière de cybersécurité afin d’identifier les zones nécessitant une amélioration. 
2. Évaluation de la sécurité des produits : Effectuer des évaluations approfondies pour garantir l’identification et la sécurité des produits.  
3. Mise à jour des instructions destinées aux utilisateurs : Fournir une documentation claire et complète à l’intention des utilisateurs en veillant à ce que tous les produits soient accompagnés d’une documentation conforme aux normes de la réglementation. 
4. Gestion des vulnérabilités : Mettre en place un processus d’identification et de partage des vulnérabilités. 
5. Revue de l’organisation interne : Mettre en œuvre une procédure permanente pour assurer la conformité, couvrant les points clés mentionnés ci-dessus et surveiller les changements de produits ou de législation qui pourraient impliquer de nouveaux écarts à remédier. 

En conclusion, le Cyber Resilience Act représente un cadre complet pour renforcer la cybersécurité des produits numériques au sein de l’UE. La conformité avec cette réglementation nécessite une préparation approfondie. Pour les entreprises, se conformer au CRA n’est pas seulement une obligation légale, mais aussi une opportunité d’améliorer leur position sur un marché de plus en plus conscient des enjeux de cybersécurité. 

Cet article Cyber Resilience Act : Une révolution qui redéfinit la sécurité des produits et transforme l’écosystème est apparu en premier sur RiskInsight.

Historique

Remontons dans le temps : nous n’allons pas parler des différentes révolutions industrielles, mais notre histoire commence à l’entame des années 70. A l’époque, pas de réseau Ethernet, de modèle OSI ou même d’informatique. Les systèmes de production industriels reposent sur des mécanismes physiques à travers l’utilisation de signaux pneumatiques ou électriques. Les années 70 voient l’arrivée des premiers principes d’automatisation, et l’intégration des premiers équipements intelligents : les automates de programmation industrielle. Ces équipements permettent une mutualisation des ressources, un automate pouvant gérer plusieurs entrées et sorties électriques, et donc de centraliser la gestion des processus. Les automates intègrent aussi des modules de communications, et les systèmes industriels voient alors l’apparition des premiers bus réseau, avec l’utilisation de protocoles de communication série.

Ce modèle d’architecture continuera de se développer dans les années 80 avec la multiplication des protocoles industriels, notamment sur le modèle « Controller-Workers » : Un automate principal contient la base de données centralisée et joue le rôle de chef d’orchestre en étant relié aux « Workers », correspondant à d’autres automates, cartes d’entrées/sorties déportées, etc… Cette architecture permet de simplifier la programmation des processus en un point unique, et aussi la communication avec les organes de visualisation type interface homme-machine ou SCADA propriétaire.

Les années 90 voient la démocratisation du modèle TCP/IP et l’intégration de l’informatique « classique » dans les environnements industriels : plus besoin d’équipements propriétaires, un logiciel SCADA peut maintenant s’installer sur des systèmes classiques… encore faut-il que ces ordinateurs puissent communiquer avec les automates ! Des cartes de réseaux séries existent, mais les protocoles industriels commencent à s’adapter pour fonctionner sur du réseau Ethernet classique. Peu à peu, on remplace les automates maîtres afin de leur permettre d’utiliser les protocoles TCP/IP sur le réseau principal, tout en continuant à avoir des cartes réseaux séries pour les équipements de terrain. Et puis ce fut au tour des équipements de terrain de s’adapter à la standardisation de l’utilisation de TCP/IP plus ou moins partout, faisant qu’aujourd’hui l’utilisation de communications séries est minime. Même les entrées/sorties électriques tendent aujourd’hui à être délaissées au profit des liaisons IP sur des capteurs et actionneurs, via par exemple l’utilisation de connectiques « Single Pair Ethernet » assurant une connexion économique et peu encombrante.

Evolution des architectures terrains

On en arrive donc aujourd’hui à pouvoir rencontrer régulièrement l’architecture suivante : Un réseau physique industriel « principal » (en topologie étoile ou en anneau) sur lequel on retrouve tous les équipements de supervision et de communications avec l’extérieur (SCADA, Data Historian, poste opérateur…) ainsi que les automates « controllers », qui chacun possèdent un second port réseau. Ce second port réseau permet de créer sur chaque automate un sous-réseau isolé sur lequel se trouve les équipements au plus proche du processus physique. L’automate controller a alors un rôle de « pivot fonctionnel », échangeant d’un côté avec le SCADA principalement, et de l’autre avec les équipements de terrain via les registres de données de l’automate. Cette architecture peut être déclinée de plusieurs façon, par exemple en remplaçant l’automate pivot par un serveur classique, ou en combinant plusieurs couches de réseaux isolés avec un serveur SCADA possédant deux ports réseau, séparant le réseau industriel principal et le réseau de supervision dans lequel on retrouverait les automates controller sur lesquels se fait une nouvelle séparation avec des réseaux de terrain.

Exemple d’architecture industrielle intégrant des réseaux de terrain

Maintenant l’historique abordé, parlons du présent et notamment des trois évolutions qui nous amènent aujourd’hui à questionner la pertinence de ce modèle d’architecture :

• L’industrie 4.0 qui a changé l’exposition des réseaux industriels, passant d’un modèle isolé vers un modèle ultra-connecté afin de répondre aux enjeux de big data, d’interconnexion avec le Cloud, de jumeau numérique, etc…
• La standardisation des technologies industrielles permettant de se détacher des fournisseurs industriels, via le développement de « Soft PLC » sur Linux ou Windows embarqué ou l’utilisation de protocoles industriels standardisés type OPC-UA.
• L’introduction des solutions de cybersécurité dans le cœur du réseau industriel comme les serveurs de mise à jour, des pare-feux, des antivirus voire EDR ou même des sondes de cartographie, dont la présence prend sens avec la modernisation des infrastructures informatiques et le développement de la cybersécurité en milieu industriel.

Pour étudier la pertinence des réseaux de terrain face à ces nouveaux enjeux, nous allons aborder quatre sujets de sécurité opérationnelle : la sécurité des réseaux, la détection & cartographie, la gestion des mises à jour et les accès distants.

Sécurité réseau

La première question à se poser est simple : Quel est l’avantage des réseaux de terrain d’un point de vue cybersécurité ? Cet avantage se traduit dans le principe même du modèle d’architecture : l’utilisation d’un équipement en pivot offre une isolation physique entre un réseau industriel et un réseau de terrain. Il n’est donc par principe impossible de faire communiquer directement les deux réseaux, la transmission d’informations se faisant à travers une base de données (registres pour les automates, base de données OPC pour un serveur…). Pas besoin de pare-feu ou de diode : aucun flux ne peut aller d’un réseau à un autre, ce qui représente le meilleur moyen de se protéger d’une propagation vers les équipements de terrain.

Mais cette séparation via un équipement physique non-dédié au réseau est-elle vraiment infaillible ? Sur un équipement fonctionnant avec un système « classique » Windows ou Linux standard, la réponse est non. Il existe de multiples exemples d’attaques convertissant ces systèmes en pivot, exploitant les nombreuses possibilités offertes : exploitation de protocole d’accès distant type RDP, VNC ou SSH, RAT, implant C2C… De ce fait, une séparation avec ce type de système ralentira un attaquant mais ne réduit finalement pas fortement les possibilités d’atteindre les réseaux de terrain qui existeraient sur d’autres cartes réseaux.

Pour le cas d’un automate « classique », il s’agit la plupart du temps d’un équipement fonctionnant sur un système d’exploitation propriétaire qui offre peu de fonctionnalités : à minima il permet de faire tourner des programmes industriels et de communiquer avec un ou plusieurs protocoles industriels, et peut optionnellement contenir des serveurs plus classiques type HTTP ou FTP. L’équipement propose donc beaucoup moins de fonctionnalité qu’un ordinateur ou serveur, et n’a pas vocation à permettre des passerelles entre ses différentes cartes réseaux… du moins, c’est ce qu’on a tendance à croire. Il a été cependant prouvé qu’il est possible de créer des passerelles entre les différents ports réseaux d’un automate : via des travaux de recherches comme ceux de Nicolas Delhaye and Flavian Dola présentés lors de la GreHack 2020 (la vidéo ici), mais surtout plus concrètement à travers le malware Pipedream découvert en 2022. Notamment, ce malware permet de créer des routes sur des automates Schneider afin de les transformer en proxy et leur donner la capaciter de router n’importe quel protocole vers les réseaux de terrain.

Illustration du fonctionnement du module Pipedream ciblant les équipements Schneider

Nous avons donc la preuve que même dans le cas d’une séparation par un automate, le modèle n’est pas infaillible, mais il permet tout de même de fortement réduire les risques en n’exposant les réseaux de terrain qu’à des attaques très avancées.

Cartographie et supervision

Suite au paragraphe précédent se pose naturellement la problématique suivante : comment superviser un réseau dont le point fort est d’être isolé ? Premièrement au sujet de la journalisation, le constat actuel est que les automates et équipements industriels sont encore très peu inclus dans les périmètres de supervision de sécurité : pour des raisons techniques, tous les équipements n’étant pas forcément en capacité de remonter des journaux type syslog, mais aussi organisationnel, les SOC manquant encore de maturité pour exploiter correctement les journaux d’évènements de ce genre d’équipement industriel.

Afin de combler ce manque de visibilité, les environnements industriels sont de plus en plus sujet à l’installation d’une sonde réseau, permettant de répondre aux besoins de supervision et de cartographie. Les systèmes qui rentrent dans le périmètre d’application de la Loi de Programmation Militaire sont notamment dans l’obligation d’installer une sonde de détection qualifiée par l’ANSSI. Sur le plan technique, il est possible de faire communiquer des réseaux isolés avec une sonde en utilisant des TAPs réseau, qui ont pour fonction de copier le trafic réseau de manière passive pour permettre l’écoute dudit trafic. Sur le plan stratégique, les réseaux de terrain sont rarement l’endroit à surveiller côté réseau. On privilégiera les points d’interconnexions avec les autres réseaux (entreprise, fournisseur…) ou les équipements critiques pour le pilotage comme le SCADA.

Exemple d’architecture de supervision intégrant les réseaux de terrain

La solution des TAPs n’est cependant pas applicable pour des sondes « actives » qui vont chercher à faire de la cartographie en questionnant les différents équipements sur le réseau. Mais ce type de solution est rarement mis en place dans un contexte industriel afin d’éviter de « stresser » le réseau et les équipements.

Le modèle des réseaux de terrain reste donc compatible en se concentrant sur la supervision du réseau, avec l’installation de sonde pour de la détection, ainsi que de la cartographie passive. La remontée de journaux systèmes des automates et équipements industriels reste encore trop peu pertinente vis-à-vis des capacités d’analyse des SOC.

Mise à jour

Pour pouvoir faire des mises à jour, il est nécessaire d’avoir une interconnexion réseau avec un système permettant la redescente de ces mises à jour, ce qui s’oppose à l’isolement des réseaux de terrain. Le besoin de mise à jour en milieu industriel rend-il le modèle de réseau de terrain obsolète ?

Le maintien en condition de sécurité est un sujet complexe dans le cas des systèmes industriels : besoin de disponibilité fort empêchant toute intervention lourde, systèmes isolés d’internet ne permettant pas le téléchargement des mises à jour par le réseau… Dans le cas de réseaux composés principalement d’automates, les mécanismes de mise à jour ont évolué en prenant en compte ces contraintes, si bien qu’aujourd’hui les parcs automates maintenus à jour sont rares (même sur une base annuelle), et ces mises à jour sont principalement déployées manuellement par la maintenance. L’utilisation de réseaux de terrain pour cloisonner l’architecture n’entrave pas l’application de ces mêmes mécanismes sur les automates.

En revanche, l’intégration des technologies IT change la donne : l’une des premières solutions de sécurité recommandée sur un parc Windows est la mise en place d’un serveur WSUS pour centraliser le déploiement des mises à jour, le même principe étant aussi applicable pour des technologies Linux. Nous arrivons donc ici à une nouvelle contrainte des réseaux de terrain possédant des équipements type Soft-PLC ou PC opérateur dédié : un cloisonnement par double carte réseau empêche la centralisation de la gestion des mises à jour, obligeant la mise en place d’un processus d’application manuelle des patchs qui peut être complexe et chronophage sur un nombre d’équipements important.

Cette contrainte doit tout de même être évaluée par rapport au besoin. L’argument principal en faveur des mises à jour est le fait qu’elles permettent de corriger des vulnérabilités augmentant la surface d’attaque d’un équipement. Le modèle des réseaux terrain isolant fortement les systèmes, leur surface d’attaque est par définition déjà fortement réduite. Il est donc acceptable que ceux-ci ne soient pas constamment à jour, et dans ce cas une mise à jour manuelle et annuelle des équipements répond au besoin.

Ce modèle ne convient cependant pas avec les besoins des antivirus d’être à jour constamment pour garantir une protection optimale. C’est pour cela qu’il est nécessaire dans ce cas de s’appuyer sur le fait d’avoir des systèmes bougeant très peu dans le temps, ce qui facilite l’utilisation dans le temps de solution de filtrage applicatif en liste blanche type AppLocker ou WDAC (voir notre article sur le filtrage applicatif).

Finalement, les pratiques de mises à jour en milieu industriel se sont adaptées au principe même d’isolation réseau permettant de réduire ces besoins. Ces pratiques demandent cependant le durcissement des équipements à leur installation, ainsi que la mise en place de solutions permettant de maintenir le niveau de sécurité des systèmes avec un minimum de maintenance à effectuer.

Accès distant

Après avoir abordé les flux « automatisés » des mises à jour, qu’en est-t-il des flux initiés par un utilisateur pour accéder à un équipement à distance pour des opérations métier ou de maintenance ? Pour des automates, ces accès sont rares : ils n’ont pas besoin d’actions humaines pour effectuer leurs tâches, et dans le cas de maintenance effectuée en interne, elle est souvent réalisée en accédant à l’automate depuis le réseau sur lequel il se trouve (les réseaux dédiés à l’administration pour les automates sont encore très rares). Dans le cas où l’automate est accessible depuis le réseau de production principal, la maintenance peut être centralisée depuis un point de connexion unique. Par contre, les réseaux de terrain étant isolés du réseau de production, les automates s’y trouvant sont accédés en allant brancher l’ordinateur portable de maintenance au “bon” commutateur interconnectant les différents équipements du sous-réseau, voire même directement sur le port USB de l’automate avec une liaison série.

Les limitations apparaissent par contre pour des réseaux de terrain avec des équipements maintenus par un fournisseur ou prestataire de maintenance. En effet, la maintenance à distance est devenue le moyen privilégié, et il est assez rare aujourd’hui d’avoir du personnel tier de maintenance à disposition pour se déplacer physiquement sur site à tout moment. La solution la plus souvent rencontrée pour faire face à cette problématique est l’installation d’une terminaison VPN directement sur un réseau de terrain, avec un tunnel relié au prestataire. Cela répond effectivement à la problématique, mais contourne aussi tout le principe d’isolement des réseaux de terrain, qui sont alors exposés en cas de compromission du prestataire.

On atteint ici la plus grande limite du modèle de réseau terrain, renforcée qui plus est avec la tendance à la centralisation des accès distant et l’installation de solution type bastion qui ne peuvent pas couvrir les accès aux réseaux de terrain du fait de leur isolement.

Conclusion

L’existence des réseaux de terrain est principalement historique, du fait des anciens modèles d’architecture en controller/worker et de la mise en place graduelle du modèle TCP/IP dans les réseaux industriels. Ces modèles d’architecture se sont adaptés au cycle de vie des systèmes : ils sont très peu accédés par des utilisateurs et sont conçus pour fonctionner en autonomie en remontant les données à l’automate controller.

Le cloisonnement est le principal point fort des réseaux de terrain : transformer un automate en rebond sur deux interfaces réseaux différentes est une technique d’attaque très avancée. Afin de détecter de possibles attaques, des solutions existent pour mettre en place de la supervision sur des réseaux isolés, notamment via des TAPs.

L’autre avantage de l’isolement réseau est de réduire les efforts à faire sur le maintien en condition de sécurité. Le besoin de mise à jour d’un équipement isolé n’est forcément pas le même que sur un équipement utilisé par un humain et interagissant avec des réseaux tiers. Les équipements isolés ayant un cycle de vie avec peu de changement, l’effort doit être mis sur le durcissement à la mise en service.

A l’inverse, l’isolation de ces réseaux posent de nombreuses problématiques sur les accès distants : il est possible de les limiter quand la gestion du parc industriel est en interne, mais ils sont essentiels dans le cas où un prestataire doit intervenir à distance. Afin d’éviter les initiatives locales ou les solutions à la main des tiers, il est recommandé de mettre en place une solution d’accès distant maîtrisée (VPN, bastion…), vers les équipements accédés à placer dans un sous-réseau dédié avec un point d’entrée filtré et maîtrisé.

En synthèse, le modèle de réseau terrain est encore aujourd’hui pertinent. Cependant, les tendances récentes, notamment liées à l’industrie 4.0, vont poser de nouvelles problématiques : L’apparition notamment des Industrial IOT, impliquant la mise en place de bus IoT interconnectés avec l’extérieur, remet en question la pertinence d’avoir des réseaux IP isolés cohabitant avec des bus IoT plus exposés.

Sources

Dragos Analyzing PIPEDREAM: Results from Runtime Testing
https://www.dragos.com/blog/analyzing-pipedream-results-from-runtime-testing/

GreHack 2020: A full chained exploit from IT network to PLC’s unconstrained code execution
https://www.youtube.com/watch?v=PfdoaxYkmUE

Cet article Les réseaux de terrain : l’historique des systèmes industriels à l’épreuve du futur est apparu en premier sur RiskInsight.