IKT-Grundschutz für Vertragspartner von IV-Stellen | Lexipedia

Organisation

Classification NON CLASSÉ

Protection informatique de base <Nom du partenaire contractuel>

Partenaire contractuel Nom du partenaire contractuel

Version / date V0.1 / XX.XX.XXX

Description Description de l'objet informatique à protéger

Suivi des modifications

Version Date Auteur Description

Table des matières

Page de couverture

Généralités

Signatures

Exigences en matière de sécurité

Abréviations

Nom du partenaire contractuel NON CLASSÉ

Mise en œuvre de la protection informatique de base

Généralités

Les exigences minimales en matière de sécurité informatique (protection informatique de base) sont présentées ci-après sous forme de tableau. Une aide pour documenter la manière dont les mesures de sécurité sont mises en œuvre est ainsi disponible.

Les exigences en matière de sécurité informatique correspondent à celles de la directive sur la protection informatique de base dans l'administration fédérale (Si001 version 5.0). Elles peuvent être modifiées ou adaptées.

Entrée en vigueur et remaniement permanent

Ce moyen auxiliaire (modèle) est adapté par l'OFAS quand la directive est modifiée. La version la plus récente se trouve toujours sur le site Internet d'application des assurances sociales (https://sozialversicherungen.admin.ch/fr/).

Tailoring

Le document de mise en œuvre (par ex. mesures exécutées) peut être complété. Des exigences peuvent aussi être désignées comme « non résolues dans cet objet informatique à protéger » si elles ne doivent pas être résolues dans cet objet ou si elles ne s'appliquent pas.

Validité

La validité de ce document est de cinq ans au maximum.

Résumé

Objet à protéger

Description de l'objet à protéger.

Analyse des besoins de protection

Résumé des informations (évaluation) de l'analyse des besoins de protection.

Récapitulatif des éventuelles autorisations spéciales et risques résiduels correspondants

Récapitulatif et évaluation des mesures n'ayant pas été mises en œuvre et nécessitant une autorisation spéciale conformément à la directive Si001, version 5, ch. 1.3.

directive Si001, version 5, ch. 1.3.

Remarques finales

Remarques finales et conclusions importantes relatives à l'objet à protéger.

Bases juridiques

Description des bases juridiques sur lesquelles repose l'objet à protéger.

Nom du partenaire contractuel NON CLASSÉ

Signatures

Les signataires confirment par leurs signatures que les exigences de la protection informatique de base sont mises en œuvre et respectées, et que, selon leur évaluation, tous les fournisseurs de prestations participant à l'exploitation de l'objet à protéger répondent aux exigences les concernant.

Le responsable de l'objet à protéger, le DSIO et le responsable du processus d'affaires doivent toujours apposer leur signature.

Rôle Date / Nom / Signature

DSIO de partenaire contractuel

Autorité habilitée de partenaire contractuel

DSIO de l'OAI

Autorité habilitée de l'OAI

D'autres signatures peuvent être ajoutées.

→Les signatures peuvent aussi être apposées sous forme électronique (dans un PDF).

Nom du partenaire contractuel

Exigences minimales de sécurité définies

Exigences

O Organisation

O1 [Responsabilité] Une personne (au sein de l'UA responsable) doit être nommée responsable de l'objet à protéger. Compétente pour mettre en œuvre la présente directive, elle doit avoir conscience de ses responsabilités et disposer de connaissances techniques suffisantes pour les assumer.

Pour les applications, il s'agit du responsable Pour tout autre objet à protéger, il convient d une personne responsable (au sein de l'organi responsable de l'objet à protéger) selon la mê

O2.1 [Documentation] Une documentation à jour, harmonisée avec celle des FP participants, doit être disponible pour l'objet à protéger. Elle doit couvrir toute la durée de vie (cycle de vie) de l'objet, et notamment : a) la chaîne d'approvisionnement (supply chain) ; b) les mesures de protection physiques c) les éléments, les fonctions et les paramètres importants pour la sécurité ; d) la gestion des clés lors de l'emploi de procédés cryptographiques ; e) les modalités et les processus en cas de modification (dans le cadre de la gestion des changements), de réparation, d'élimination et de perte ; f) les accords contractuels, et g) les processus et activités d'audit destinés à contrôler la mise en œuvre et

Il est nécessaire de fournir des documents aus et exhaustifs que possible sur les aspects men contre de l'objet à protéger pour permettre de avis sur la sécurité et de tirer des conclusions contre n'étant pas exhaustive, il est fortement d'ajouter des commentaires sur d'autres sujets concernant la let. g) : les processus et activité doivent être exécutés par un organe indépend de telle sorte que la disponibilité des objets à affectée le moins possible (en d'autres termes dysfonctionnements et les interruptions d'exp doivent être aussi limités que possible).

le respect de la présente directive.

O2.2 [Documentation] Lorsque l'objet à protéger (système informatique ou application) n'est pas exploité dans une zone de l'administration fédérale (par ex. sur un nuage public), la documentation doit préciser : a) comment le besoin de protection de l'objet peut être satisfait dans cet environnement, et b) les mesures de sécurité complémentaires garantissant que cette situation n'engendre ni menace ni risque supplémentaires pour les autres objets à protéger de l'administration fédérale.

Selon le principe 1 (forme de la fourniture de l'exploitation externe d'un objet à protéger (p un nuage public) n'est admise que si cet envir satisfait aux besoins de protection dudit objet préciser ici de manière aussi détaillée que po modalités de garantie de protection de l'objet mesures de sécurité complémentaires, d'ordre organisationnel ou juridique, qui garantissent menace ou de risque supplémentaire pour les à protéger de l'administration fédérale.

O3 [Continuité de l'activité] Concernant l'objet à protéger, la continuité de l'activité doit être garantie et documentée dans le cadre d'un processus de gestion de la continuité des services informatiques (IT Service Continuity Management, ITSCM) ou de gestion de la continuité de l'activité (Business Continuity Management, BCM), conformément au besoin identifié lors de l'analyse des besoins de protection.

Les processus ITSCM et BCM doivent satisfair avérés et faire l'objet d'une documentation ex rend compte notamment du danger croissant cyberattaques.

O4 [Cyberincidents] L'objet à protéger doit faire partie du processus de gestion des cyberincidents. En cas d'incidents majeurs, les travaux sont coordonnés par le NCSC.

Un exemple d'un tel processus est documenté https://intranet.ncsc.admin.ch/dam/ncscintr dokumente/partner/20210217- Bewaeltigung_Cybervorfaelle.pdf.download.p Bewaeltigung_Cybervorfaelle.pdf. En cas de c l'objet à protéger doit être intégré dans un tel défini en coordination avec le FP et le BP con notamment éprouver le processus pour les ob protéger concernés.

P Personnel

P1.1 [Sensibilisation et formation] Tous les utilisateurs de l'objet à protéger doivent être formés et sensibilisés à la sécurité informatique selon leur niveau de responsabilité et leur fonction.

La forme de sensibilisation et de formation n' l'UA compétente ou la personne responsable d protéger peut en décider librement. Elle doit tenir compte des rôles liés à l'objet à protéger ex. administrateur, superutilisateur, utilisateu organiser les formations en conséquence.

P1.2 [Sensibilisation et formation] Tous les utilisateurs de l'objet à protéger doivent connaître les directives d'application importantes pour celui-ci et s'engager à les respecter.

Une liste des directives d'application est dispo l'adresse : https://intranet.dti.bk.admin.ch/is home/ikt-vorgaben/einsatzrichtlinien.html. C s'applique en particulier à l'utilisation de syst et/ou de périphériques privés lors du travail m responsable de l'objet à protéger peut fixer le d'application que doivent respecter les utilisa

P2 [Obligation d'annonce] Tous les utilisateurs de l'objet à protéger doivent signaler aussi rapidement que possible au service compétent (par ex. Service Desk) les événements critiques en matière de sécurité tels qu'un comportement anormal ou douteux du système ou une perte physique.

La description des événements critiques ne sa exhaustive (sauf en cas de perte physique). El respecter le besoin en protection de l'objet à p laisse une liberté d'appréciation à l'UA respon son délégué à la sécurité informatique.

T Aspects techniques

T1 [Exploitation] L'objet à protéger doit être exploité conformément à l'état de la technique, en tenant compte des directives et recommandations de sécurité usuelles de la branche (meilleures pratiques).

Il est impossible de décrire précisément l'état technique dans chaque cas, mais il faut l'étab exemple avec les délégués à la sécurité inform compétents (DSIO et DSID). Il est possible de NCSC en cas de question de fond ou pour s'in des considérations technologiques : https:// intranet.ncsc.admin.ch/ncscintra/fr/home/ dokumentation/empfehlung_technologiebetra

T2.1 [Configuration et paramétrage] Avant sa première mise en service, l'objet à protéger doit être configuré et paramétré de façon à : a) être protégé contre un accès non autorisé ; b) être renforcé, si cela est techniquement possible, et être exploité dans une configuration minimale nécessaire à l'accomplissement des tâches qui ne peut pas être modifiée par un utilisateur (en d'autres termes, les interfaces, modules et fonctions non utilisés doivent être désactivés), et c) permettre un enregistrement et une évaluation rapide des activités et événements importants pour la sécurité (avec horodatage).

Cette exigence peut être considérée comme u intégrante des meilleures pratiques. En raison importance, elle est toutefois présentée sépar

T2.2 [Configuration et paramétrage] L'activation, la modification, la désactivation et la désinstallation des configurations et des paramètres de sécurité requièrent une autorisation.

Le renforcement de la sécurité au sens de l'ex n'a de sens que si les configurations et les par sécurité ne peuvent être activés, modifiés, dé désinstallés que par des personnes autorisées.

T3 [Environnement de production] L'environnement de production de l'objet à protéger doit être séparé des autres environnements éventuels (par ex. destinés au développement et/ ou aux tests). En cas de séparation logique, les dispositifs et mesures de sécurité correspondants doivent être justifiés et documentés.

La séparation physique est en principe préfér toutefois elle s'avère impossible ou qu'elle n'e justifiable sur le plan économique, il est possi procéder à la séparation logique. Les disposit de sécurité visant la séparation logique doive justifiés et documentés.

T4 [Faiblesses et vulnérabilités] Il faut rechercher régulièrement et, de préférence, automatiquement (par ex. avec un scanneur de sécurité) les faiblesses et les vulnérabilités de l'objet à protéger avant sa mise en service et, en fonction de son besoin de protection et de son exposition à Internet, pendant l'exploitation également. On fera appel au NCSC pour les faiblesses et vulnérabilités critiques.

Dans l'idéal, il faut intégrer l'objet à protéger système de gestion des vulnérabilités aussi co automatisé que possible.

T5.1 [Authentification et autorisation] Tout accès à un objet à protéger doit être authentifié conformément au besoin de protection de ce dernier et autorisé selon le principe « Least Privilege » ou « Need to know ».

Le contrôle des accès doit être en principe co respecter les principes mentionnés. L'authentii être réalisée localement ou à l'aide d'une ou d connexions réseau. Dans le second cas, elle es dans son intégralité (c.-à-d. authentification l terminal et authentifications éventuelles sur d proxys).

T5.2 [Authentification et autorisation] Tous les droits d'accès à l'objet à protéger doivent être gérés dans le cadre d'un processus défini et documenté et être tenus à jour en tout temps. En particulier, la nécessité et l'exactitude des droits seront examinées au moins une fois par an, les droits (ou comptes) qui ne sont plus nécessaires étant supprimés.

Dans le cadre du processus mentionné ici, la des pouvoirs entre l'autorisation et l'attributio d'accès doit être prise en compte lorsque cela et judicieux, et documentée. Pour adapter les d'accès à de nouvelles conditions (par ex. en c changement ou de fin des rapports de service ou de convention d'utilisation des collaborate concernés), il est judicieux de lier ce processu des RH.

T5.3 [Authentification et autorisation] Seuls des moyens d'authentification et de vérification d'identité gérés dans le cadre d'un processus défini et documenté peuvent être utilisés pour l'objet à protéger. Ce processus doit couvrir l'ensemble du cycle de vie du support (y c. les possibilités d'accès en cas d'urgence, le blocage, la réinitialisation, la révocation et l'élimination).

Cette exigence tient compte avant tout de l'im égale (sur le plan technique) des processus de des moyens mis en œuvre en cas d'utilisation d'authentification et de vérification d'identité

T6.1 [Authentification de l'utilisateur] L'utilisateur d'un SPT ou d'un système serveur doit être authentifié par un moyen d'authentification et de vérification d'identité présentant au moins le niveau de sécurité « moyen » selon l'annexe B ou grâce à une authentification à deux facteurs.

La nécessité d'une authentification à deux fac d'une décision prise par le Conseil fédéral le 4 Pour les collaborateurs de la Confédération, o certificats de classe B de la SG-PKI. En cas de serveur, l'authentification de l'utilisateur se ré niveau du système d'exploitation.

T6.2 [Authentification de l'utilisateur] L'utilisateur d'un système MDM doit être authentifié par une procédure compatible avec le système d'exploitation en question, telle qu'un numéro d'identification personnel (NIP) ou une authentification biométrique (par ex. Touch ID ou Face ID pour les appareils iOS). Le NIP doit comporter au moins six caractères et ne pas être trop simple.

La différence conceptuelle entre un mot de pa est expliquée dans la considération technolog « Passwörter vs. PINs » du 29 juin 2012. Sont considérés comme des NIP trop simples les nu d'utilisateur, les dates de naissance et les suit telles que 111111, 123456 et 654321.

T6.3 [Authentification de l'utilisateur] L'utilisateur d'un élément du réseau doit être authentifié par un moyen d'authentification et de vérification d'identité présentant au moins le niveau de sécurité « élevé » selon l'annexe B.

Comme l'accès aux éléments du réseau compo risques d'abus élevés, il est nécessaire de reco moyen d'authentification et de vérification d'i présentant au moins le niveau de sécurité « él

T7.1* [Mots de passe] Le mot de passe a) doit être personnel ; b) doit être unique ; c) ne doit pas être communiqué à un tiers ; d) ne doit pas être écrit ou doit être consigné de manière sécurisée ou être géré par un programme de chiffrement des mots de passe ; e) doit comporter au moins dix caractères (18 caractères pour les utilisateurs ayant des droits élevés), au moins trois des quatre catégories suivantes devant être présentes : majuscules, minuscules, chiffres et caractères spéciaux ; f) ne doit pas être ordinaire ni se référer à l'utilisateur (par ex. aucun attribut tel que l'identifiant de l'utilisateur, son nom, son prénom ou sa date de naissance).

Cette exigence est marquée d'un astérisque (* signifie qu'elle peut faire l'objet d'une dérogat ci est justifiée et consignée dans le document œuvre des mesures de protection informatiqu dans l'administration fédérale » ou dans le co sécurité de l'information et de protection des (SIPD). Précision concernant la let. a) : les co impersonnels ne peuvent être octroyés que da particuliers dûment justifiés. Ils ne peuvent ê que pour accéder à des objets à protéger ne p un besoin de protection accru (protection de Précision concernant la let. b) : il est notamm d'utiliser le même mot de passe pour s'authen plusieurs systèmes informatiques et applicatio concernant la let. d) : sur le SPT, il faut utilis gestion personnelle des mots de passe (couch

T7.2* [Mots de passe] Un mot de passe initial attribué de manière administrative doit être modifié dès sa première utilisation.

T7.3* [Mots de passe] : Lorsque le mot de passe est changé, il faut s'assurer que le nouveau ne correspond pas à l'un des dix mots de passe utilisés précédemment.

T7.4* [Mots de passe] : Après cinq tentatives erronées au plus, le mot de passe doit être bloqué. Il ne peut être débloqué que dans le cadre d'un processus défini.

T7.5 [Mots de passe] : Le mot de passe doit être changé sans délai si l'on soupçonne que des personnes non autorisées en ont connaissance ou qu'il y a un abus.

En cas de doute, il est possible de s'adresser a la sécurité informatique (DSID et DSIO).

T7.6* [Mots de passe] : Au niveau du serveur, il faut veiller à ce que le mot de passe ne puisse pas être lu en texte clair ni être compromis facilement dans le cadre d'une autre attaque.

Les mots de passe ne doivent pas être enregis clair, mais sous forme d'image de fonction à s (par ex. fonction de hachage cryptographique l'idéal, la fonction doit être paramétrée avec u à l'utilisateur.

T8.1 [Accès administratifs et accès à distance] Les accès administratifs à l'objet à protéger doivent être exécutés de manière documentée et contrôlée. En particulier, ils doivent bénéficier d'une sécurisation cryptographique tout en étant enregistrés et évalués de façon compréhensible.

La sécurisation, l'enregistrement et l'évaluatio cryptographiques sont particulièrement impo prévenir ou reconnaître les activités non auto d'accès administratif. À cet effet, la sécurisati cryptographique doit s'appuyer non seulemen l'authentification, mais aussi sur la protection confidentialité et de l'intégrité des données.

T8.2 [Accès administratifs et accès à distance] Les systèmes informatiques utilisés pour les accès administratifs doivent être dédiés à cette tâche et, de préférence, exploités dans une zone de gestion. L'utilisation des comptes (privilégiés) correspondants doit pouvoir être attribuée à une personne. De plus, les comptes ne peuvent disposer que des droits d'accès minimaux requis, dont la durée de vie sera aussi courte que possible. Ils doivent être affectés à l'une des couches d'un modèle de couches et ne peuvent servir qu'à l'administration au sein de cette couche (pour éviter une escalade des privilèges). En particulier, les comptes ne peuvent pas être employés pour des accès non

Ces exigences découlent avant tout du projet Credential Theft » (MCT). Les droits d'accès à se prêtent le mieux aux comptes gérés dans le solution Privileged Access Management (PAM droits ne sont valables que pour la durée d'un administrative précise. Ce modèle de couches ici est défini, par exemple, dans le cadre de la E033 en cours d'élaboration.

administratifs à Internet.

T8.3 [Accès administratifs et accès à distance] Un accès direct à distance est autorisé pour un prestataire externe si : a) le propriétaire de l'objet est d'accord et consent à d'éventuelles violations du secret de fonction conformément aux procédures spécifiques. b) l'accès est réalisé via un compte dédié et l'utilisateur est authentifié par un moyen d'authentification et de vérification d'identité présentant au moins le niveau « moyen » selon l'annexe B ; c) l'utilisation de ce compte est limitée dans le temps et surveillée ; d) lorsque cela est techniquement possible, l'accès est exécuté via un jump host ; e) le raccordement technique du compte au réseau

Cette exigence résulte d'une reformulation et au niveau du contenu aux exigences des direc sécurité en vigueur jusqu'à présent.

bénéficie d'une sécurisation cryptographique (par ex. avec SSH), et f) la possibilité d'auditer les processus externalisés est garantie en tout temps.

I Informations (données)

I1* [Admissibilité des systèmes informatiques] Les informations importantes pour les affaires peuvent être enregistrées et traitées sur des systèmes informatiques uniquement lorsqu'ils appartiennent à une UA de l'administration fédérale ou lorsque le respect des exigences techniques de sécurité énoncées dans le présent document est défini contractuellement pour ces systèmes (par ex. dans le cadre d'une solution en nuage).

Cette exigence doit garantir l'enregistrement traitement de données importantes pour les af seulement sur des systèmes informatiques que l'administration fédérale peut contrôler effica les plans technique ou organisationnel et juri

I2.1 [Confidentialité et intégrité] La confidentialité et l'intégrité des informations importantes pour les affaires doivent être protégées à tout moment par des procédés cryptographiques, conformément à leur besoin de protection et en tenant compte des particularités physiques (cela vaut également pour les données de test et les données de production utilisées à des fins de test). Lorsque les informations sont cryptées, les clés utilisées à cet effet doivent être gérées de telle sorte qu'une récupération et, partant, un décryptage des informations soient possibles à tout moment. En général, cela requiert une administration complexe des clés (avec un mécanisme de récupération des

En particulier, les informations ayant un beso protection accru qui sont enregistrées sur les de systèmes serveurs physiques sans protectio particulière doivent être sécurisées grâce à un du disque dur.

clés) et un test régulier de la récupération.

I2.2 [Confidentialité et intégrité] Les systèmes informatiques utilisés doivent être appropriés pour garantir la protection de la confidentialité et de l'intégrité des informations.

Par exemple l'enregistrement et le traitement d'informations classées CONFIDENTIEL, de do sensibles ou de profils de la personnalité sur d MDM ne sont pas autorisés ou ne le sont que d'une communication vocale chiffrée [E027].

I3.1 [Disponibilité] La disponibilité des informations importantes pour les affaires doit être garantie à tout moment, conformément au besoin de protection.

La disponibilité des informations importantes affaires constitue en principe l'objectif princip atteindre.

I3.2 [Disponibilité] Les UA responsables des informations doivent disposer d'une stratégie de sauvegarde et la mettre en œuvre. Cette stratégie doit prévoir un principe multigénérationnel et un stockage hors ligne des principaux jeux de données afin que celles-ci puissent être récupérées même en cas de maliciels chiffrant les informations (rançongiciel).

Lorsque l'UA responsable est un bénéficiaire d (BP), la stratégie de sauvegarde peut égaleme du FP. Elle doit cependant être vérifiée et con comme appropriée par le BP pour l'objet spéci protéger. Des exercices réguliers concernant c revêtent alors une importance primordiale : l de récupérer les données après une perte doit contrôlée régulièrement et confirmée par le B

I4 [Supports de données] Les supports de données sur lesquels sont enregistrées les informations importantes pour les affaires doivent à tout moment être protégés conformément au besoin de protection de ces informations. Des processus appropriés doivent être définis et mis en œuvre pour la réparation et l'élimination de ces supports.

Lors de l'élimination des supports de données particulier veiller à ce que leur contenu ou le enregistrées ne puissent pas être reconstitués. également « Recommandation concernant la de supports électroniques de données dans l'a fédérale » (https://intranet.ncsc.admin.ch/da fr/dokumente/empfehlungen/Empfehlungen- Vernichtung_HW_V1-0-f.pdf.download.pdf/Em Vernichtung_HW_V1-0-f.pdf).

S Systèmes informatiques

S1 [Affectation à une zone] Le système informatique doit être affecté à une zone et exploité conformément à la réglementation de cette zone.

Un système informatique qui ne peut être affe autre zone fait partie d'Internet. Il n'existe alo réglementation de zone. De plus, il se peut qu éléments du réseau ne soient attribués ni à un Internet. Ils doivent être documentés.

S2 [Mises à jour et correctifs] Il faut s'assurer que le(s) fabricant(s) du système informatique propose(nt) pendant toute sa durée de vie des mises à jour et des correctifs (patchs) qui peuvent être vérifiés et installés rapidement, ou que le système informatique est exploité dans une zone dédiée et aussi hermétique que possible (par ex. zone technique), des mesures de sécurité complémentaires garantissant que cette situation n'engendre ni menace ni risque supplémentaires pour les autres objets à protéger de l'administration fédérale. Si un remplacement est prévu, le système informatique peut encore être exploité pendant deux ans au plus, à condition que la poursuite de l'exploitation soit

Pour les SPT qui ne sont pas connectés en per réseau, il faut s'assurer que des mises à jour e correctifs sont installés au moins une fois par de correctif, il faut prendre en compte la com différents niveaux) des divers types de logicie ex. application, intergiciel, base de données, d'exploitation, virtualisation, serveur, stockag FP doit tenir à jour les niveaux inférieurs, ce de collaborer avec le BP pour modifier l'appli besoin. Les applications de tiers exigent un co maintenance pour permettre de procéder à de modifications nécessaires dans le cadre de la correctifs.

exposée dans un concept SIPD.

S3.1 [Comptes de service] Les comptes utilisés par les services système (comptes de service) doivent être spécifiques et posséder uniquement les droits minimums requis pour fournir les services.

Un compte de service est réputé spécifique lo utilisé que pour un service.

S3.2* [Comptes de service] Les comptes de service doivent être gérés automatiquement et requérir une authentification cryptographique forte. Idéalement, celle-ci s'appuiera sur une cryptographie asymétrique, les clés privées utilisées à cet effet devant être consignées de manière sûre. Si l'authentification repose sur des mots de passe, ils doivent être sensiblement plus forts (et plus longs) que pour l'authentification de l'utilisateur.

Les exigences relatives à l'authentification de service sont plus élevées que pour les compte La cryptographie asymétrique se prête bien à situation. En cas de recours à des mots de pas doivent être sensiblement plus forts (et plus l pour l'authentification de l'utilisateur. Il n'exi longueur minimale définie, car elle dépend d relative du compte de service.

S4.1 [Protection de l'intégrité et protection contre les maliciels] L'intégrité des composantes logicielles utilisées sur le système informatique doit être garantie (par ex. à l'aide de signatures numériques). En particulier, l'intégrité de chaque système serveur ayant un besoin de protection accru doit être contrôlée régulièrement.

Cette exigence découle entre autres de la déc Conseil fédéral du 16 décembre 2009. Voir au considération technologique «Integritätsprüfu Systemen» (https://intranet.ncsc.admin.ch/da ncscintra/de/dokumente/technologiebetrach Technolgiebetrachtung- Integritaetspruefung_von_Systemen_V1-0- d.pdf.download.pdf/Technolgiebetrachtung- Integritaetspruefung_von_Systemen_V1-0-d.pd

S4.2 [Protection de l'intégrité et protection contre les maliciels] Lorsqu'une perte d'intégrité est détectée, le système informatique doit être immédiatement coupé du réseau, sécurisé et examiné. Si sa compromission est confirmée, il doit être intégralement supprimé et reconfiguré.

Toute perte d'intégrité indique une comprom système informatique. Dans ce cas, il est néce séparer immédiatement le système informatiq de le sécuriser et de l'examiner, puis, en cas d compromission confirmée du système, de l'eff entièrement et de le réinitialiser.

S4.3 [Protection de l'intégrité et protection contre les maliciels] Le système informatique doit être intégré dans un concept de protection contre les maliciels basés sur [SB003], qui définit en particulier la marche à suivre lorsqu'un maliciel est identifié, les services à informer et la manière de le faire.

Au vu de l'importance de la protection contre dans les systèmes informatiques, il est nécess ce thème au niveau conceptuel, de manière a que possible. Il est possible de prendre [SB00 base.

S5.1 [Ordinateurs clients de l'administration fédérale] Les supports de données internes non volatils (par ex. disques durs) doivent être visiblement cryptés sur un ordinateur client de l'administration fédérale. En cas de système MDM, il faut prévoir en plus une possibilité de réinitialiser à distance ses paramètres de base et de supprimer toutes les informations enregistrées localement.

Le cryptage est dit visible lorsqu'il s'effectue (automatiquement) sans action de l'utilisateu ordinateurs clients de l'administration fédéral crypter les données qu'ils stockent localement non volatile). À cet effet, il faut activer le chif disque dur (par ex. BitLocker). Pour les systèm faut prévoir en plus une possibilité de réinitia paramètres de base et de supprimer toutes les enregistrées localement.

S5.2 [Ordinateurs clients de l'administration fédérale] En l'absence d'activité de l'utilisateur, l'accès à l'ordinateur client de l'administration fédérale doit être bloqué automatiquement (au bout de 15 min. au plus pour les SPT et de 3 min. au plus pour les systèmes MDM). Une activation manuelle des blocages d'accès au système doit aussi être possible. Si un tel blocage n'est pas possible pour des raisons techniques, l'accès aux ordinateurs clients de l'administration fédérale non surveillés doit être protégé physiquement (par ex. par verrouillage de la pièce).

Il faut garantir que des tiers ne puissent pas a d'authentifications d'utilisateurs réussies. Pou faut soit verrouiller automatiquement l'accès ordinateurs clients de l'administration fédéral d'inactivité de l'utilisateur, soit protéger phys l'accès aux clients. Dans les situations délicate à fait envisageable de combiner les deux poss

S5.3 [Ordinateurs clients de l'administration fédérale] La fonction de démarrage automatique en cas de raccordement de supports de données externes (par ex. clés USB) doit être désactivée sur un ordinateur client de l'administration fédérale.

Cette mesure permet d'éviter l'implantation e de maliciels dans les systèmes informatiques utilise des supports de données externes non

S5.4 [Ordinateurs clients de l'administration fédérale] Les utilisateurs d'un SPT ne peuvent avoir aucun droit d'administrateur local.

Cette exigence sert à empêcher la propagation par l'intermédiaire de comptes d'utilisateurs c

S5.5 [Ordinateurs clients de l'administration fédérale] Un accès administratif au SPT à des fins d'assistance n'est autorisé qu'avec l'autorisation explicite préalable de l'utilisateur.

Cette exigence sert à empêcher tout accès adm un SPT à l'insu de l'utilisateur.

S6.1 [Périphériques] Un périphérique peut être utilisé lorsque a) il a été acquis auprès d'un service d'achat de la Confédération, et b) son intégrabilité et sa sécurité élémentaire sont dûment confirmées par le FP.

Cette exigence sert à garantir l'utilisation exc périphériques contrôlés au sein de l'administr fédérale (l'exigence 6.4 contient de plus ampl informations sur les périphériques privés). Pr concernant la let. b) : l'intégrabilité signifie, p que l'appareil peut être relié aux registres des collaborateurs de l'administration fédérale po fonctions comme ScanToMail.

S6.2 [Périphériques] Le périphérique doit être configuré de manière minimale par le FP et protégé contre les modifications non autorisées (de la configuration).

La configuration minimale et le renforcement sécurité concernent aussi les périphériques.

S6.3 [Périphériques] Lorsque l'appareil est utilisé pour imprimer des documents classifiés : a) il doit être exploité localement ou doit permettre d'authentifier l'utilisateur, et b) les supports de données internes non volatils (par ex. disques durs) doivent pouvoir être écrasés conformément aux recommandations en vigueur, cet écrasement pouvant être déclenché manuellement par l'utilisateur ou automatiquement.

Précision concernant la let. b) : des « recomm vigueur » sont par ex. DoD 5220.22-M ou NIS

S6.4 [Périphériques] L'utilisation de périphériques privés lors du travail mobile doit respecter la directive d'application [E026].

Cette exigence réglemente indirectement l'uti périphériques privés, en particulier dans le ca télétravail.

A Applications

A1.1 [Achat / développement] L'application doit être achetée ou développée dans le cadre d'un processus méthodique, en tenant compte précocement des directives et recommandations en vigueur en matière de sécurité (meilleures pratiques).

Pour le développement d'applications Web, il exemple, prendre en considération les directi recommandations de l'Open Web Application Project (OWASP), qui couvrent également la du code du programme.

A1.2 [Achat / développement] Lors du développement de logiciels d'application, il faut notamment veiller à a) conserver le code source de manière sûre ; b) réglementer clairement et contrôler de manière compréhensible l'accès aux référentiels correspondants ; c) surveiller les processus Build et n'exécuter les modifications dans la Build Pipeline que sous supervision ; d) tester régulièrement les logiciels, et e) garantir à tout moment leur intégrité (par ex. à l'aide de signatures numériques).

Cette exigence concerne le processus de déve logiciels d'application et les meilleures pratiq découlent. Pour procéder au développement a logiciels dans le cadre du modèle SAFe, il con comme critères d'achèvement (definition of d exigences posées en matière de sécurité. Les d sécurité doivent être mis à jour pour chaque i produit (product increment) et être présentés en tant que critères d'acceptation.

A2 [Entretien et maintenance] Un entretien et une maintenance professionnels doivent être garantis pour l'application et ses composantes (par ex. bibliothèques logicielles) pendant toute la durée de vie. Cela englobe en particulier l'installation de mises à jour et de correctifs (patchs) réguliers qui sont techniquement nécessaires à l'exploitation ou à la sécurité.

L'entretien et la maintenance revêtent une im particulière pour les logiciels d'application (e bibliothèques logicielles utilisées). Le respect procédures et des processus professionnels es L'outil « OWASP Dependency-Check » notamm de vérifier les relations avec d'autres biblioth logicielles et les éventuelles failles qui en résu (https://owasp.org/www-project-dependency

Z Zones

Z1.1 [Conformité] La zone doit être conforme au modèle de zones de la Confédération et avoir un propriétaire, un nom unique, une réglementation (policy) de zone et un exploitant (cela ne s'applique ni à Internet ni à la zone Internet). Si elle comprend des systèmes informatiques et des applications qui sont exploités en dehors de l'administration fédérale (par ex. sur un nuage public), le raccordement au réseau doit être défini dans la réglementation de zone.

L'unicité peut découler, par exemple, de l'ind propriétaire comme suffixe dans le nom de la propriétaire met plusieurs fois en œuvre une noms correspondants doivent être clairement L'exploitant est un FP qui gère la zone au niv technique du réseau sur mandat du propriéta propriétaire de la zone est un FP, le propriéta l'exploitant peuvent être identiques. Lorsque propriétaire modifie la réglementation d'une un délai raisonnable de mise en œuvre doit ê l'exploitant.

Z1.2 [Conformité] L'exploitant doit veiller à ce que seules les communications admises par la réglementation de zone soient exécutées depuis et vers la zone et, grâce à des mesures de sécurité complémentaires appropriées (par ex. isolement et segmentation), à ce qu'elles n'engendrent ni menace ni risque supplémentaires pour les autres systèmes informatiques et applications au sein et hors de la zone.

La réglementation de zone pose un cadre pou sein et hors de la zone. L'exploitant doit veille l'exécution correcte de la réglementation et o l'approbation du propriétaire de zone. Il doit pour des dérogations à la réglementation pon requises pour l'exploitation.

Z1.3 [Conformité] La zone doit être intégrée au registre que le DSID tient et met à la disposition du NCSC. Le DSID est compétent lorsqu'une UA du département agit en tant que propriétaire ou exploitant de la zone.

Cette exigence est nécessaire pour offrir une v d'ensemble des zones exploitées au sein de l'a fédérale. Il se peut qu'une zone soit consignée (une fois du point de vue du propriétaire, l'au de vue de l'exploitant) au vu de la définition compétences.

Z2.1 [Accès] Un accès restreint à une zone est autorisé uniquement pour les personnes et les processus automatisés qui ont été authentifiés par un moyen d'authentification et de vérification d'identité présentant au moins le niveau « moyen » (le niveau « faible » suffit pour les appareils de mesure). Les dérogations suivantes sont admises : a) accès anonymes et personnalisés créés dans le cadre des applications de cyberadministration utilisables par une large partie de la population dans une zone de serveurs. Les pages Web correspondantes doivent être sécurisées avec TLS (HTTPS) et protégées contre les attaques automatisées grâce à des formulaires (par ex. Captcha) ; b) accès temporaires

Un accès est dit restreint lorsque des mesures (par ex. filtrage de paquets IP) sont mises en limiter à un seul ou à quelques systèmes infor applications définis et aux protocoles indispe l'accès. Dans tous les autres cas, l'accès est rép Précision concernant la let. b) : dans ce cas, l des systèmes serveurs correspondants par rap autres systèmes informatiques de la même zo documentée soit dans la réglementation de zo conjointement avec toutes les mesures de séc complémentaires visant à minimiser les risqu documentation de sécurité de l'application. B le propriétaire de la zone doit également don accord à l'exploitation des systèmes serveurs.

pour charger des données sur un système serveur ; c) accès automatisés effectués avec le consentement d'un propriétaire de zone dans le cadre des contrôles de sécurité des sites Internet (scans). En cas d'accès à une zone présentant un besoin de protection accru (par ex. SZ+), le moyen d'authentification et de vérification d'identité doit avoir au moins le niveau « élevé » selon l'annexe B. Les dérogations a) et b) susmentionnées ne sont alors pas autorisées.

Z2.2 [Accès] Un accès illimité à une zone n'est admis que pour les personnes qui se connectent via un ordinateur client de l'administration fédérale, sont authentifiées par un moyen d'authentification et de vérification d'identité présentant au moins le niveau « élevé » selon l'annexe B et utilisent une connexion cryptographique sécurisée (par ex. avec SSH).

L'accès illimité à une zone doit être en princip est réservé à certains cas d'utilisation (par ex. administration). Dans cette situation, il fa des exigences renforcées en matière d'accès a et de sécurité des communications.

Z3 [Communication interzone] Toute communication interzone doit passer par une PEZ. Celle- ci doit s'assurer que la communication est conforme à la réglementation des zones concernées. Pour ce faire, les modèles et relations de communication autorisés doivent être définis aussi précisément que possible dans les réglementations des zones (dans l'idéal sur la couche applicative et sous la forme d'une allow list). Si un test de conformité dans une PEZ n'est pas possible (par ex. dans le cas d'une communication cryptée de bout en bout), il peut également être effectué par les systèmes informatiques dans les zones elles- mêmes (au sens d'un PEP). Toutefois, des mesures complémentaires d'atténuation des

Bien que la première phrase s'applique en pri également à la communication d'une sous-zon zone supérieure, il est possible d'y renoncer d justifiés documentés dans les réglementations zones correspondantes. Il faut également prév exigences renforcées pour l'accès aux système informatiques ainsi que pour la sécurité et l'e des communications.

risques doivent alors être prévues et documentées.

Z4.1 [PEZ] Les PEP exploités dans une PEZ ne peuvent être gérés de manière virtualisée qu'au sein de la zone. En d'autres termes, aucun système informatique des autres zones ne peut être exploité sur le matériel utilisé en commun.

Z4.2 [PEZ] Le propriétaire d'une PEZ ou d'une infrastructure proxy Web doit définir la manière dont l'accès aux ressources sur Internet est réalisé et quels accès sont autorisés. Il peut le faire dans la réglementation de zone de la PEZ ou dans une directive distincte. Le NCSC peut compléter les ensembles de règles correspondants. Dans le champ d'application du service informatique standard Communication de données, la réglementation est édictée dans le cadre de [Si004].

Le propriétaire d'une PEZ ou d'une infrastruct Web exploitée dans une PEZ est responsable d définition des accès autorisés aux ressources s Le NCSC doit avoir la possibilité d'ajouter des les ensembles de règles en fonction des vecteu actuellement observés.

Z4.3 [PEZ] La connexion d'une PEZ à Internet doit être hautement disponible, voire redondante. En outre, l'exploitant doit s'assurer grâce à des mesures appropriées que les systèmes informatiques séparés d'Internet par la PEZ sont dûment protégés contre des attaques de déni de service (denial of service, DoS) ou de déni de service distribué (distributed DoS, DDoS).

Les attaques DDoS constituent un problème d important. Pour se protéger efficacement con attaques, la connexion d'une PEZ à Internet d hautement disponible, voire redondante.

Z5.1 [Surveillance] La communication au sein d'une zone doit être surveillée de telle sorte que les attaques puissent être identifiées de manière aussi fiable que possible (par ex. grâce à des systèmes de détection ou de prévention d'intrusion [intrusion detection system, IDS; intrusion prevention system, IPS]) et que l'exploitant puisse réagir rapidement et adéquatement en cas de besoin.

Comme la surveillance d'une zone pour préve attaques s'effectue aisément de manière autom suppose le recours à des systèmes de détectio prévention d'intrusion. Il n'est toutefois pas o recourir à ces derniers. Tout autre moyen per reconnaître les dangers à temps et d'y réagir d appropriée est également envisageable. Dans surveillance, aussi bien l'enregistrement des d leur contrôle et leur évaluation réguliers afin des anomalies se révèlent importants.

Z5.2 [Surveillance] Les informations collectées lors de la surveillance doivent être conservées et protégées contre des manipulations ultérieures, conformément aux dispositions légales (en particulier, la législation sur la protection des données et l'ordonnance du 22 février 2012 sur le traitement des données personnelles liées à l'utilisation de l'infrastructure électronique de la Confédération). En cas de besoin, elles doivent être mises à la disposition du NCSC.

Les dispositions légales mentionnées ici ne so nécessairement exhaustives, c'est-à-dire qu'il fait exister d'autres directives à prendre en co surveillance au sens de cette exigence.

Nom du partenaire contractuel

Références

Abréviations

BA Bureautique

BCM Gestion de la continuité des activités (Business Continuity Management)

BP Bénéficiaire de prestations

CA Autorité de certification (Certification Authority)

CAPTCHA Completely Automated Public Turing test to tell Computers and Humans Apart

CC Critères communs

CDF Contrôle fédéral des finances

CVC Communication vocale chiffrée

CZ Client Zone

DAKO Transmission de données (Datenkommunikation)

DDoS Déni de service distribué (Distributed DoS)

DIS Draft International Standard, projet de norme internationale

DNS Système de noms de domaine (domain name system)

DoS Déni de service (Denial of Service)

DSIO Délégué à la sécurité informatique de l’unité administrative

EAL Niveau d’évaluation (Evaluation Assurance Level)

FIDO Fast ID Online

FP Fournisseur de prestations

IAM Gestion des identités et des accès (Identity and Access Management)

ID Identifiant

IdO Internet des objets

IDS Système de détection d’intrusion (Intrusion Detection System)

IEC Commission électrotechnique internationale (International Electrotechnical Commission)

IKE Internet Key Exchange

IP Protocole Internet (Internet Protocol)

IPS Système de prévention d’intrusion (Intrusion Prevention System)

IPSec IP security, sécurité du protocole Internet

ISO Organisation internationale de normalisation

IT Technologies de l’information

ITSCM Gestion de la continuité des services informatiques (IT Service Continuity Management)

JSON JavaScript Object Notation

JWT JSON Web Token

LoA Niveau d’assurance (Level of Assurance)

LSI Loi sur la sécurité de l’information

MDM Gestion des appareils mobiles (Mobile Device Management)

NCSC Centre national pour la cybersécurité

NIP Numéro d’identification personnel (Personal Identification Number, PIN)

NW Accès illimité au réseau (Network Full Access)

OPCy Ordonnance sur les cyberrisques

OSI Open Systems Interconnection

OTP Mot de passe à usage unique (One-Time Password)

OWASP Open Web Application Security Project

PAM Gestion des accès privilégiés (Privileged Access Management)

PEP Point d’application des règles (Policy Enforcement Point)

PEZ Zone d’application des règles (Policy Enforcement Zone)

PKI Infrastructure à clés publiques (Public Key Infrastructure)

RA Accès restreint au réseau (Restricted Access)

SAML Security Assertion Markup Language

Schuban Analyse des besoins de protection (Schutzbedarfsanalyse)

SG-PKI Swiss Government PKI

SIPD Sécurité de l’information et protection des données

SMS Short Message Service

SPT Système de poste de travail

SS Service standard

SSH Secure Shell

SSO Single Sign-On

SZ Zone de serveurs (Server Zone)

SZ+ Zone de serveurs avec besoin de protection accru

TCP Transmission Control Protocol

TIC Technologies de l’information et de la communication

TLS Sécurité de la couche de transport (Transport Layer Security)

TNI Transformation numérique et gouvernance de l’informatique (secteur de la ChF)

TPM Trusted Platform Module

TT Terminal de tiers

UA Unité administrative

Oui

Non

Partiellement

Non pertinent

Non résolu dans cet objet protégé