SF 1. Situation 

Ce document fait partie du cadre de cybersécurité Storyfox. Ce document définit les contrôles de sécurité minimaux relatifs au contrôle d'accès et à la gestion des droits. Ces règles sont obligatoires à tous les systèmes d'information de Storyfox pour tous les employés, clients et partenaires de Storyfox.

Ces règles ont été définies par le CISO et validées par le CODIR.

SF 2. Principes

Storyfox est une société française qui fournit en mode SAAS une solution vidéo pour les entreprises. La sécurité est au cœur de notre activité. Nous consacrons beaucoup de ressources et d'énergie à :

* Sécuriser notre système d'information ;

* Construire des solutions sécurisées pour nos clients

* Héberger les données de nos clients avec une sécurité maximale.

Construire une relation durable et de confiance avec nos clients est essentiel pour nous. Avec l'exposition croissante des plateformes web aux menaces de sécurité informatique, nous prenons notre rôle très au sérieux pour protéger nos infrastructures et celles que nos clients nous confient et travaillons quotidiennement à la consolidation de nos services. C'est pourquoi Storyfox a mis en place une démarche de sécurité dans le but d'obtenir des labels et certifications de référence sur le marché, qui sont pour vous un gage de qualité et de confiance. Nos collaborateurs adhèrent à cette démarche et y contribuent activement au quotidien. Responsables, ils s'assurent que les règles de sécurité sont connues, comprises et appliquées, dans leur domaine d'intervention et dans le cadre de leur mission. Vigilants, ils sont en alerte permanente lors de leurs différents usages et utilisations des systèmes d'information, afin de détecter d'éventuels incidents et d'adopter le comportement adéquat dans une situation à risque. Cette politique de sécurité des systèmes d'information est applicable dans le cadre des relations de service entre Storyfox et ses Clients.

Chez Storyfox, l'apprentissage et l'application des mesures de sécurité commencent dès l'embauche des employés, afin que la culture de la sécurité soit diffusée dans toute l'entreprise. Chaque employé est conscient des menaces qui pèsent sur les systèmes d'information et connaît donc ses responsabilités par rapport à ceux-ci. Cela lui permet d'assumer un rôle permanent d'acteur.

Pour cela, une formation au bon usage des ressources informatiques (basée sur le guide de l'ANSSI : https://www.ssi.gouv.fr/uploads/2017/01/guide_cpme_bonnes_pratiques.pdf) est dispensée à chaque salarié dès son arrivée à Storyfox et est complétée régulièrement par des formations complémentaires.

SF 3. Organisation Responsable de la sécurité informatique (CISO) :
Nicolas Bellot nicolas@storyfox.io
Codir : Julie Machillot, Pauline Campanella, Pierre Castanet, Nicolas Bellot
Security Advisory Board : Julie Machillot, Investisseurs

SF 4. Contrôle d'accès et gestion des droits
SF 4.1. Risques Les contrôles de sécurité définis ici doivent être mis en œuvre pour faire face aux menaces sur notre Système d'Information (SI) : - Cyberattaques - Vol/fuite de données confidentielles - Saturation de l'infrastructure - Cyberespionnage L'application de la politique de cybersécurité vise à limiter les impacts des risques majeurs de cybersécurité définis au niveau de l'entreprise : - Fraude - Ciblage d'attaques massives - Divulgation ou vol d'informations - Corruption de données Ainsi, à tout moment, Storyfox doit pouvoir répondre aux questions suivantes :

- Quels sont les accès d'un utilisateur ?

- Qui a accès à une information ou à un actif ?

- Qui est responsable de la validation de ces accès ?

Par cette directive, Storyfox affirme sa volonté d'assurer le respect des lois et règlements nationaux et internationaux, d'accroître sa performance et de préserver la valeur de ses actifs.

SF 4.2.Objectifs
Pour empêcher l'accès non autorisé aux informations, cette directive définit des règles de contrôle d'accès et de gestion des droits. Ces règles visent à : accorder l'accès à l'information à une personne connue, accorder l'accès à l'information à un utilisateur autorisé et protéger la confidentialité des informations secrètes d'authentification, accorder l'accès à l'information sur la base du besoin d'en connaître (principe du "moindre privilège") en fonction des besoins de l'entreprise, accorder les droits d'accès à partir d'une source fiable.

SF 4.3. Gestion de l'identification

SF 4.3.1. Identifiant unique (ID)
Afin d'assurer la traçabilité, chaque utilisateur doit disposer d'un identifiant personnel lorsqu'il accède à une ressource du SI.

Les identifiants doivent être construits avec une convention de nommage spécifique. L'utilisation d'un même identifiant personnel par différents utilisateurs est strictement interdite.

SF 4.3.2. Compte client et compte technique 2 types de comptes clients :

- Admin pour gérer l'espace de travail du client

- Utilisateur pour utiliser le service

Les comptes techniques ont pour but de gérer le service et sont utilisés par les employés de Storyfox.

SF 4.3.3. ID de l'administrateur
Les identifiants de l'administrateur qui accordent un accès avec des privilèges élevés doivent être différents des identifiants de l'utilisateur attribués aux administrateurs. Tous les identifiants qui accordent un accès privilégié (Admin ou Operator par exemple) doivent être séparés/différents de l'identifiant standard de l'utilisateur.

Les identifiants d'administrateur doivent être utilisés uniquement pour des tâches d'administration et non pour accéder à un système en tant qu'utilisateur standard.

SF 4.4. Gestion de l'authentification

SF 4.4.1. Authentification des utilisateurs

Un compte utilisateur personnel et une étape d'authentification sont nécessaires pour accéder aux ressources informatiques restreintes (non publiques). Les informations secrètes d'authentification (mot de passe par exemple) doivent être définies pour chaque utilisateur en respectant la politique de mot de passe locale/entité.

La procédure de connexion doit respecter les règles suivantes :

▪ Ne pas afficher les identifiants du système ou de l'application tant que la procédure de connexion n'est pas terminée avec succès.

▪ Ne pas fournir de messages d'aide pendant la procédure de connexion qui pourraient aider un utilisateur non autorisé.

▪ Ne valider les informations de connexion que lorsque toutes les données d'entrée ont été complétées. Si une condition d'erreur se produit, le système ne doit pas indiquer quelle partie des données est correcte ou incorrecte.

▪ Mettez fin aux sessions inactives après une période d'inactivité définie, en particulier dans les endroits à haut risque tels que les zones publiques ou externes hors de la gestion de la sécurité de l'organisation ou sur les appareils mobiles.

▪ Protéger contre les tentatives de connexion par force brute.

SF 4.4.2. Système de gestion centralisée des comptes
La gestion centralisée des comptes est la méthode privilégiée d'authentification et d'autorisation pour contrôler l'accès aux composants du SI (applications/services/ressources).

Si un composant ne peut pas être intégré à un système de gestion centralisée des comptes, ce composant doit mettre en œuvre un niveau de sécurité élevé (procédure de connexion sécurisée, protection des informations secrètes d'authentification, traçabilité...) pour fournir le même niveau de protection des informations d'identification.

SF 4.4.3. Authentification forte et informations secrètes d'authentification préférées
L'authentification qui permet l'accès à une application / un service / une ressource critique directement exposée à l'Internet à partir d'un dispositif non géré doit appliquer une authentification forte, pour tout type d'utilisateur.

Les outils collaboratifs sont considérés comme critiques. Si une authentification multi-facteur est impossible, l'accès au service doit être strictement limité au réseau interne ou aux dispositifs authentifiés. L'authentification qui permet l'accès à des composants techniques ou logiques avec des privilèges élevés doit utiliser une authentification multi-facteur lorsque cela est possible. Ceci est obligatoire dans les endroits à haut risque tels que les zones publiques ou externes qui échappent à la gestion de la sécurité de l'organisation (accès à distance par exemple) ou sur les appareils mobiles. Cette multi authentification peut être mise en place par un accès VPN ou un bastion administrateur.

Si une authentification forte est impossible, une politique de mot de passe plus stricte s'applique aux comptes à privilèges (longueur du mot de passe, durée de vie réduite...), l'accès doit être filtré par IP et une liste formelle de ces comptes doit être maintenue. Dans la mesure du possible, une politique de mot de passe à connaissance zéro doit être utilisée. Les authentifications doivent de préférence utiliser le Single Sign On (SSO) lié à la solution SSO.

Un utilisateur / mot de passe dédié devrait être le dernier choix pour s'authentifier à une application / un service / un appareil.

La première connexion à la solution SSO peut utiliser les mécanismes suivants :
1. sur le dispositif : Solutions biométriques (ex : visage / empreinte digitale)
2. Certificat / jeton / application d'authentification sur smartphone
3. Mot de passe

SF 4.4.4. Politique de gestion et protection des mots de passe
En cas d'utilisation d'un mot de passe, les règles suivantes doivent être respectées par défaut :

▪ Longueur minimale du mot de passe : 12 caractères

▪ Complexité du mot de passe : utiliser au moins 3 règles suivantes : lettres majuscules et minuscules, inclusion d'un ou plusieurs chiffres numériques, inclusion de caractères spéciaux tels que @, #, $

▪ Durée de vie maximale du mot de passe : 180 jours

▪ Interdiction de réutiliser le mot de passe : 4 derniers mots de passe

▪ Interdiction de changer de mot de passe pendant 24 heures

L'utilisateur doit changer son mot de passe lors de sa première connexion.

Le mot de passe fournisseur par défaut doit être modifié après l'installation de systèmes ou de logiciels. Si l'utilisateur souhaite modifier son mot de passe, une ré authentification est obligatoire. Pour toute demande de modification (mot de passe oublié par exemple), l'identité de l'utilisateur doit être vérifiée, et la demande doit être enregistrée. Pour les comptes génériques (ou comptes de service), la confidentialité des mots de passe doit être maintenue lorsqu'ils sont partagés (par exemple, changer fréquemment et le plus tôt possible les mots de passe lorsqu'un utilisateur privilégié quitte ou change de poste, les communiquer entre utilisateurs privilégiés avec des mécanismes appropriés...).

Le mot de passe doit être communiqué à l'utilisateur de manière sécurisée. L'identifiant et le mot de passe doivent être communiqués à l'utilisateur par des canaux différents. Les mots de passe doivent être tenus secrets. Comme il peut être impossible pour les utilisateurs de se souvenir de tous leurs mots de passe associés à plusieurs comptes, l'utilisation d'outils de gestion des mots de passe approuvés par l'équipe de sécurité est recommandée (OnePassword). L'utilisation d'outils de gestion des mots de passe est obligatoire pour les utilisateurs à hauts privilèges, ou si ces informations doivent être partagées (compte générique par exemple). Une protection adéquate des mots de passe doit être mise en place lorsque les mots de passe sont utilisés comme information secrète d'authentification dans des procédures de connexion automatisées (ex : mécanisme de cryptage). Sur les systèmes/applications, les mots de passe doivent être stockés de manière irréversible ou utiliser des algorithmes forts et ne doivent pas être lisibles/non chiffrés par les administrateurs du SI.

SF 4.4.5. Journal d'audit d'authentification
Chaque tentative d'authentification réussie ou non (tout comme les tentatives de force brute) aux systèmes du SI doit être enregistrée. Elle doit être horodatée, associée à un compte et enregistrée. Les journaux d'authentification sont conservés pendant une période prédéfinie, conformément aux exigences légales, pour une enquête ultérieure ou un suivi du contrôle d'accès. Par défaut, les fichiers journaux sont conservés pendant un an.

SF 4.5. Droits d'accès

SF 4.5.1. RBAC
Pour chaque application, les liens entre les rôles métier et les droits d'accès aux applications doivent être formalisés dans une matrice (base du " role-based access control "). La matrice doit décrire quelles fonctions/données peuvent être accédées par un rôle particulier, et les niveaux de droit (ex : lire, écrire, supprimer et exécuter). Ensuite, les droits d'accès doivent être accordés en fonction de cette matrice. Les droits d'accès doivent être accordés en fonction du besoin de savoir (principe du "moindre privilège"). Les droits d'accès doivent être accordés de manière à préserver la séparation des tâches (SoD). Par exemple, une séparation des tâches doit être préservée entre l'exécution et le développement au sein de l'équipe informatique.

SF 4.5.2. Provisionnement et autorisation des droits d'accès
Des formulaires de demande d'accès doivent être utilisés pour demander, modifier ou supprimer des privilèges d'accès. Ces formulaires comprennent les informations suivantes :

▪ Date de la demande.

▪ Informations sur l'utilisateur qui a besoin des privilèges d'accès.

▪ Applications et rôles correspondants.

▪ Date de validité.

Chaque étape du processus de gestion des privilèges d'accès (demande, approbation et mise en œuvre technique) doit être consignée et enregistrée pour une utilisation ou un rapport ultérieur.

SF 4.5.3. Approbation et révision des droits d'accès
Chaque demande d'accès doit être approuvée par le responsable pour les utilisateurs internes et le responsable du contrat pour les utilisateurs externes.

Les propriétaires des ressources doivent s'assurer que les principes de " moindre privilège " et de " séparation des tâches " sont appliqués. Les demandes liées à des droits d'accès sensibles ou impliquant des conflits de séparation des tâches doivent également être approuvées par le CISO.

L'examen des privilèges d'accès est le processus qui consiste à vérifier que chaque compte SI s'est vu accorder les privilèges d'accès appropriés. Ces privilèges doivent être conformes aux principes du "moindre privilège" et du SdD. Les autorisations de droits d'accès privilégiés (comptes administrateurs par exemple) doivent être revues à intervalles plus fréquents (au moins tous les 6 mois). Cette revue doit être effectuée une fois par an. Le champ d'application comprend :

▪ Les comptes d'utilisateurs.

▪ Les comptes d'administrateurs.

▪ Les comptes d'utilisateurs externes.

▪ Les comptes génériques et techniques.

Des actions correctives doivent être effectuées, suite aux résultats de cette revue (suppression ou modification des privilèges d'accès). Cette revue est réalisée par le propriétaire de l'application / ressource / service et les responsables utilisateurs sous le contrôle du RSSI et doit être enregistrée. Mettre en place un moyen de rendre disponible à tout moment les droits d'accès accordés à un ID utilisateur (ou à une application/service/ressource).

SF 4.6.
Enregistrement et suppression Dans le cas d'un processus d'enregistrement pour un client, toutes ses données sont exportées vers un format exploitable. Ces données seront après validation, entièrement supprimées de notre SI.

SF 5. Sécurité et classification des données
SF 5.1. Risques
La mise en œuvre de ces règles de sécurité vise à protéger les informations de Storyfox contre les menaces suivantes : Empêcher tout accès non autorisé ou non pertinent aux informations
SF 5.2. Objectifs
Afin de prévenir ces menaces, cette directive définit des règles de classification de l'information pour s'assurer que l'information reçoit un niveau de protection approprié en fonction de son importance pour l'organisation

SF 5.3. Classification
Exposer à tous les employés de Storyfox les règles de gestion des données au sein de l'entreprise. Evaluer les impacts en cas de fuite ou de vol de données pour attribuer un niveau de confidentialité approprié afin d'identifier les mesures de sécurité nécessaires à leur protection.

SF 5.3.1. Processus
Chaque document doit appartenir à un propriétaire chargé de le classer et de déterminer les droits d'accès à celui-ci. Classifier les documents au moment de leur création (ou lors de leur prise en charge à partir de sources externes).

SF 5.3.2. Niveaux
L0 - Public : Informations et supports qui peuvent être diffusés publiquement.

Il n'y a pas d'impact de la confidentialité par la diffusion de ces informations.

L1 - Interne : Informations ou supports qui peuvent être divulgués aux utilisateurs de Storyfox si nécessaire. Une diffusion incontrôlée pourrait entraîner des impacts négatifs.

Ces informations ne doivent pas être divulguées, telles quelles, en dehors de la société Storyfox.

L2 - Restreint : Informations ou supports dont la divulgation doit être limitée à ceux qui ont besoin de les connaître pour mener à bien leurs missions. Leur divulgation pourrait nuire à la société Storyfox de manière non vitale.

L3 - Confidentiel : Ces informations ou supports ne doivent être partagés qu'entre un groupe de personnes clairement identifiées. Une divulgation ou une perte non autorisée de l'information ou du média pourrait nuire de manière significative et durable à la société Storyfox.

Définis par défaut à L0 - Interne, les documents dont la classification n'a pas été déterminée.

Le propriétaire du document (ou son responsable) doit être en mesure de déclassifier le document. Tous les documents contenant des données personnelles sensibles* (telles que décrites dans le GDPR) doivent être définis au moins au niveau L2.

SF 5.3.3. Marquage

Réaliser le marquage de la classification au moyen d'un cartouche sur le document. Si la solution de stockage le permet, effectuer un marquage électronique du document. Rendre obligatoire le marquage des en-têtes de courriel en cas de classification " confidentiel ". Prévoir un marquage de la classification sur tous les modèles de documents.

SF 5.3.4. Traitement des données
Respectez et faites respecter les règles présentées dans les tableaux ci-joints pour la création, la manipulation, le stockage, le transfert et le partage, la copie/impression et la destruction des données. Si un document non marqué est considéré comme un document de niveau L1 - Usage interne, les règles applicables à cette catégorie doivent être respectées par défaut.

SF 5.3.5. Tiers
Chaque document doit appartenir à un propriétaire chargé de le classer et de déterminer les droits d'accès à celui-ci. Classifiez les documents au moment de leur création (ou lors de leur prise en charge à partir de sources externes).

SF 6. Services, terminaux et accès au réseau
SF 6.1. Risques
Ce document définit les règles et exigences de sécurité relatives aux infrastructures réseau de Storyfox. La mise en œuvre de ces règles de sécurité vise à protéger le réseau de Storyfox (et par extension, toutes les ressources connectées au réseau) contre les menaces suivantes :

Intrusion dans le réseau et accès non autorisé aux ressources de Storyfox, Écoute du trafic de données du réseau et/ou altération des données transmises Déni de service, Le champ d'application de cette politique couvre tous les types de réseaux : aussi bien les réseaux de données que les réseaux vocaux.

SF 6.2. Objectifs

Afin de se prémunir contre ces menaces, cette directive définit des règles relatives aux réseaux, aux terminaux, aux services et aux communications pour :

- prévenir les accès physiques non autorisés ou les dommages aux ressources de Storyfox,
- prévenir les accès logiques non autorisés, les dommages et les interférences aux ressources de Storyfox,
- prévenir les mouvements latéraux malveillants,
- prévenir les fuites de données et/ou l'écoute sur le réseau.

SF 6.3. Sécurité physique
Les lignes de télécommunications des installations de traitement de l'information critiques (comme le centre de données) doivent être redondantes et souterraines ou faire l'objet d'une protection alternative adéquate.

L'accès au matériel de réseau à l'extrémité de la ligne de télécommunication (routeur, box ADSL...) doit être contrôlé (ex : monté dans un système de rack fermé ou installé dans une pièce séparée fermée).

L'accès aux panneaux de brassage, aux salles de câblage et au matériel de réseau (ex : commutateurs, routeur) doit être limité (ex : monté dans un système de rack fermé).

Si possible, les points d'accès Wi-Fi doivent être placés dans des zones inaccessibles.

Les ports des commutateurs qui ne sont pas utilisés doivent être désactivés.

Les prises réseau dans les zones publiques ne doivent pas être connectées au matériel réseau.

SF 6.4. Accès au réseau et services
SF 6.4.1. Wifi
Les technologies d'authentification, de cryptage et de contrôle d'accès au réseau au niveau de l'utilisateur des réseaux sans fil modernes, basés sur des normes, doivent être mises en œuvre avec des protocoles basés sur des spécifications cryptographiques. La fonction VLAN privé avec mod isolé et la désactivation de la fonction WPS doivent être utilisées. Le nom SSID par défaut doit être modifié.

Pour les appareils ou utilisateurs internes, l'authentification aux réseaux Wi-Fi par le biais d'un annuaire doit être mise en œuvre en utilisant des certificats de machine ou des identifiants d'utilisateur.

SF 6.4.2. Accès à distance
L'accès à distance doit être mis en œuvre en utilisant des technologies de tunneling (VPN SSL, VPN IPSEC...). Les clients d'accès à distance doivent être fortement authentifiés (ex : authentification multi-facteurs comme MFA, ...).

SF 6.4.3.Interconnexion avec les tiers
L'interconnexion avec les partenaires / fournisseurs doit être mise en œuvre en utilisant des technologies de tunneling (VPN SSL, VPN IPSEC...) et doit être formalisée et maintenue à jour. L'interconnexion doit être revue au moins une fois par an. L'authentification des deux extrémités du tunnel doit utiliser un chiffrement fort.

SF 6.4.4. Disponibilité
La disponibilité des réseaux des centres de données doit être garantie pour fournir un niveau de service élevé : mécanisme de redondance, liens Internet de secours, surveillance... doivent être définis et mis en œuvre.

Les mécanismes de reprise du réseau doivent être testés régulièrement et au moins une fois par an.

SF 6.5. Ségrégation et filtrage
La micro segmentation (création de zones sécurisées dans les centres de données et les déploiements de cloud qui permettent d'isoler les charges de travail les unes des autres et de les sécuriser individuellement) est mise en œuvre dans nos implémentations de services et d'applications et obligatoire pour l'environnement IaaS. Cette ségrégation et ce filtrage sont gérés par notre fournisseur de cloud. Nos différents environnements (développement, staging et production) sont également totalement différents et aucune donnée n'est transférée entre eux. De même, toutes les données et tous les actifs du client sont isolés et ne sont pas accessibles aux utilisateurs non autorisés.

SF 6.6. Traçabilité des trafics réseau
Une journalisation et une surveillance appropriées doivent être appliquées pour permettre l'enregistrement et la détection d'actions susceptibles d'affecter ou d'être pertinentes pour la sécurité de l'information. Au minimum, tous les paquets rejetés par un système de filtrage doivent être enregistrés. Tous les paquets rejetés et acceptés doivent être consignés depuis/vers un composant sensible connecté au réseau.

Des systèmes de détection et de prévention des intrusions dans le réseau (IDS/IPS) doivent être mis en œuvre, le cas échéant, pour détecter et refuser les activités suspectes ou non autorisées du réseau. Les systèmes anti-malware doivent être mis en œuvre de manière appropriée pour analyser et bloquer le trafic malveillant.

Les systèmes de filtrage des URL doivent être mis en œuvre de manière appropriée pour analyser et bloquer le trafic malveillant ou interdit. Reverse Proxy/WAF : Les applications sensibles doivent être surveillées du point de vue de la sécurité et peuvent nécessiter des mécanismes de sécurité supplémentaires tels que le Web Application Firewall, la collecte et la corrélation des logs... Nous utilisons les outils de notre fournisseur de Cloud pour gérer ces tâches.

SF 6.7. Gestion des points d'extrémité
Les actifs associés aux installations de traitement de l'information et de l'information doivent être identifiés. Un inventaire de ces actifs doit être établi et maintenu. Les biens maintenus dans l'inventaire doivent être détenus. Les points d'accès publics doivent être surveillés et, pour ceux qui ne sont pas situés dans des bureaux ou dans des lieux publics, situés dans un bâtiment dont l'accès est contrôlé. Le contrôle d'accès doit être opérationnel sur le terminal, notamment au démarrage et pour le déverrouillage des sessions. Le mode veille doit être activé automatiquement lorsqu'un terminal n'est pas utilisé pendant une période déterminée. Cette période doit être choisie en fonction du risque d'accès au terminal par une personne non autorisée.

Des droits avancés ne doivent pas être accordés à des utilisateurs standards (par exemple des droits d'administrateur), sauf si des dérogations spéciales, impliquant la création de comptes supplémentaires limités aux actions nécessaires, sont validées par l'équipe de sécurité.

Les droits d'accès privilégiés doivent être attribués à un ID utilisateur différent de ceux utilisés pour les activités professionnelles régulières et ne doivent pas utiliser les mêmes informations secrètes d'authentification. Les activités professionnelles régulières ne doivent pas être effectuées à partir d'un identifiant privilégié

Les terminaux doivent être sécurisés par des outils de sécurité permettant la protection contre les malwares (par exemple, antivirus, antispyware) avec un mécanisme EDR (Endpoint Detection and Response).

Tous les Endpoints fournis par l'entité doivent être inscrits dans l'outil de gestion du fournisseur de cloud et correctement gérés.

SF 6.8. Protection logicielle et matérielle
Les données temporaires (système, swap, corbeille informatique...) doivent faire l'objet d'un nettoyage régulier et automatique pour les endpoints qui n'ont pas de fonctionnalité de chiffrement de ces données temporaires. Les terminaux doivent être cryptés conformément aux exigences de classification des données. L'entité responsable doit fournir tous les moyens nécessaires pour sécuriser les données professionnelles en fonction de leur niveau de sensibilité (cryptographie, authentification forte...) Des mécanismes de sauvegarde assurant la disponibilité des données professionnelles doivent être mis en place sur tous les terminaux fournis par IT Operations, et en fonction de la sensibilité des données

La sécurité du développement et du code est assurée par les avis de sécurité de Github.

SF 6.9. Règles d'utilisation
Les utilisateurs sont responsables de l'équipement qui leur a été attribué (Il doit y avoir une signature de perception). Ils doivent le garder en sécurité afin de prévenir les risques de perte ou de vol, en utilisant les moyens disponibles dans leur entité. Tous les utilisateurs doivent être sensibilisés à l'utilisation sécurisée du terminal et à l'utilisation des outils de sécurité. Une procédure spécifique prenant en compte les exigences légales et autres exigences de sécurité de l'organisation doit être établie pour les cas de vol ou de perte de terminaux mobiles.

SF 6.10. Appareils appartenant à des particuliers
L'utilisation d'appareils mobiles appartenant à des particuliers est autorisée par la direction des RH. Il doit y avoir une séparation entre l'utilisation privée et l'utilisation professionnelle des terminaux, y compris l'utilisation de logiciels pour soutenir cette séparation et protéger les données professionnelles sur un appareil privé. Le dispositif non géré par l'entité ne doit pas avoir accès au réseau interne.

SF 7. Gestion des incidents de sécurité
SF 7.1. Risques
Ce document définit les règles de sécurité et les exigences liées à la gestion des incidents de sécurité de l'information de Storyfox. L'application de ces règles de sécurité vise à protéger les informations de Storyfox contre les menaces suivantes :

Événements de sécurité ; Incidents de sécurité ;

SF 7.2. Objectifs
Afin de prévenir ces menaces, cette directive définit les règles de gestion des incidents de sécurité de l'information pour assurer des réponses planifiées, systématiques et sereines aux incidents de sécurité de l'information, minimisant ainsi les impacts négatifs des incidents.

- détecter, signaler et évaluer les incidents de sécurité de l'information ;
- réagir aux incidents de sécurité de l'information, y compris l'activation de contrôles appropriés pour la prévention et la réduction des impacts, ainsi que pour le rétablissement après ceux-ci (par exemple dans le cadre du soutien des zones de gestion de crise) ;
- signaler les vulnérabilités de sécurité de l'information qui n'ont pas encore été exploitées pour provoquer des événements de sécurité de l'information et éventuellement des incidents de sécurité de l'information, et les évaluer et les traiter de manière appropriée ;
- tirer des enseignements des incidents et des vulnérabilités de sécurité de l'information, instituer des contrôles préventifs et apporter des améliorations à l'approche globale de la gestion des incidents de sécurité de l'information.

SF 7.3. Gestion des événements de sécurité
Les journaux d'événements clés doivent être activés, centralisés et archivés, puis corrélés et analysés sur une infrastructure dédiée afin d'améliorer la détection des incidents.

Les cas d'utilisation du SOC - condition ou événement (généralement lié à une menace spécifique) devant être détecté ou rapporté par l'outil de sécurité - doivent être définis avant le déploiement d'un SOC. Pour chaque cas d'utilisation défini, les événements de sécurité minimaux nécessaires à collecter doivent être décrits et la procédure de traitement des incidents doit être documentée.

Toutes les informations collectées à partir du système d'information (telles que les événements de sécurité, les journaux d'application ou le trafic réseau) doivent être documentées. Les informations à journaliser doivent être identifiées conformément à la réglementation locale.

Les informations collectées doivent être centralisées, et protégées contre toute atteinte à la disponibilité, l'intégrité et la confidentialité par des mesures techniques et organisationnelles (scellement, archivage...).

Chaque Système d'Information doit collecter et centraliser les événements et les logs de sécurité dans un entrepôt de données unique. Les nouveaux systèmes doivent donc être sélectionnés en fonction de leurs capacités de connexion et de reporting et doivent faciliter la collecte des données.

SF 7.4. Gestion de crise
Une organisation, un processus, des procédures et des outils doivent être définis pour guider la gestion de crise cybernétique. Après une décision prise en accord avec le CISO, la cellule de crise est déclenchée et le processus de gestion de crise est appliqué. Lors du déclenchement de la cellule de crise, et pendant toute la durée de la crise, un journal de crise est tenu à jour par un profil dûment identifié.

A l'issue de la crise, un rapport de synthèse doit être fourni, avec les actions préventives qui doivent être identifiées et réalisées pour éviter la survenue d'une crise similaire. Il doit être partagé avec le RSSI et le Codir. La cellule de crise assure une communication interne sur la crise sur une base (minimum) quotidienne. Si nécessaire, la cellule de crise demande au service communication de gérer la communication externe de l'entreprise. L'organisation, le processus et les procédures doivent être testés, sur une base annuelle, lors d'exercices de crise.

Une revue des incidents majeurs doit être réalisée dans le cadre du suivi du service de prestation (lors du comité de pilotage par exemple) et des actions préventives doivent être identifiées et réalisées pour éviter la survenue d'incidents du même type. Cette revue doit être faite dans chaque entité puis au niveau de l'entreprise, au moins une fois par an.

Tout contrat de service signé avec un fournisseur doit inclure des clauses contractuelles types concernant :

- L'obligation de signaler les incidents de sécurité pouvant avoir un impact sur l'entreprise dans les 24 heures

- L'obligation de désigner un point de contact spécifique pour la gestion de l'incident et de la crise éventuelle.

F 8. Cybersécurité
SF 8.1. Risques
La mise en œuvre de ces règles de sécurité vise à protéger les informations de Storyfox contre les menaces suivantes :

Cyberattaques, Vol/fuite de données confidentielles, Saturation de l'infrastructure.

SF 8.2. Objectifs
Afin de prévenir ces menaces, cette directive définit des règles de sécurité d'exploitation pour assurer un fonctionnement correct et sécurisé des systèmes d'information (SI).

SF 8.3. Gestion des vulnérabilités et des correctifs
Chaque actif du SI (matériel, logiciel...) doit être inventorié de manière régulière (au moins mensuellement). Chaque actif du SI doit faire l'objet d'une surveillance des vulnérabilités qui informe les administrateurs dans les meilleurs délais dès qu'une nouvelle menace peut impacter le SI.

Chaque collaborateur doit traiter les vulnérabilités applicables à son SI, et leur attribuer les niveaux de priorité suivants en fonction de leur criticité : critique, urgent, standard. Les critères d'évaluation des niveaux de priorité sont les suivants : le niveau de criticité CVSS intrinsèque, le niveau d'exposition du composant affecté, la criticité de l'activité supportée par ce composant.

Les vulnérabilités critiques doivent être surveillées et documentées. Toute gestion d'une vulnérabilité critique doit faire l'objet d'un retour d'expérience formalisé. Chaque entité doit établir une liste des vulnérabilités critiques surveillées, incluant la liste des composants affectés. Pour ce faire, des outils spécifiques tels qu'un scanner de vulnérabilité peuvent être utilisés et les informations peuvent être consolidées dans une base de données. Au minimum, un fichier Excel à jour doit être établi. Un processus de correction des vulnérabilités doit être normalisé pour prendre en compte les différents composants à traiter, dans le respect des objectifs temporels suivants :

▪ 15 jours pour les vulnérabilités critiques,
▪ 45 jours pour les vulnérabilités urgentes,
▪ Les vulnérabilités standards doivent être traitées au plus tard dans le cadre des mises à jour ou du renouvellement des composants du SI.

Si des exigences métier s'appliquent, ces vulnérabilités doivent être traitées conformément à ces exigences. OS-1.4.3 Le processus de traitement des vulnérabilités doit inclure un processus d'exception pour traiter les cas qui ne répondent pas aux objectifs de délais (ex : systèmes obsolètes, systèmes qui ne peuvent être mis à jour que dans le cadre d'une maintenance spécifique...).

Toutes ces exceptions pour les vulnérabilités critiques ou urgentes doivent être enregistrées et documentées. Un plan d'action doit être défini et proposer par exemple les mesures préventives suivantes :

▪ La séparation du système dans une zone confinée et isolée des autres systèmes, voire une déconnexion complète du réseau de l'entreprise.

▪ La mise en place d'un réseau avancé surveillant le trafic échangé avec ce composant ainsi que les journaux d'événements générés sur celui-ci.

▪ Le durcissement du composant de configuration afin de réduire sa surface d'exposition aux attaques.

Chaque entité doit mettre en place un reporting technique permettant de mesurer l'efficacité de la surveillance et de l'application des correctifs sur pas moins du périmètre incluant les postes de travail et les composants exposés sur Internet. Les différents indicateurs à fournir sont laissés à l'appréciation de chaque entité et des clients en fonction de leur pertinence pour mesurer l'efficacité du processus. Certains indicateurs doivent être fournis dans le cadre de contrôles automatiques ou manuels récurrents.

SF 8.4. Gestion des sauvegardes
Les opérations de sauvegarde doivent être effectuées conformément à des plans de sauvegarde spécifiques. Les différentes opérations de sauvegarde doivent être surveillées. Les éventuels dysfonctionnements dans l'exécution de ces opérations doivent être traçables. En cas de dysfonctionnements récurrents (par exemple, échec de deux sauvegardes successives), un incident doit être enregistré et un plan d'action doit être formalisé pour y faire face.

La traçabilité des opérations de sauvegarde doit être assurée. L'historique des durées est à définir en cohérence avec la stratégie de sauvegarde et/ou les plans de sauvegarde.

Les sauvegardes doivent être protégées par les mesures de sécurité définies dans la stratégie globale de sauvegarde ou dans les plans de sauvegarde spécifiques (par exemple, cryptage des sauvegardes, externalisation des supports physiques...).

Le système de sauvegarde peut également être utilisé pour l'archivage des données. Dans ce cas, il convient de s'assurer que les besoins d'archivage ont été identifiés avec l'entreprise, et que le système de sauvegarde mis en œuvre répond à ces besoins :

▪ Durée de conservation des données archivées (qui peut être très longue)
▪ Possibilité de lire les données après la fin de vie du système
▪ Respect des obligations légales et réglementaires pour certaines archives (horodatage, intégrité, non-répudiation...).

La gestion des sauvegardes est assurée par notre fournisseur de Cloud.

SF 8.5. Gestion de l'administration
L'accès aux environnements de production pour leur administration doit se faire au travers d'une passerelle de rebond unifiée garantissant au minimum les éléments de sécurité suivants :

▪ Gestion centralisée des accès
▪ Filtrage des flux d'administration
▪ Traçabilité des opérations d'administration au moins pour les connexions en console
Il est recommandé d'appliquer cette règle pour l'accès aux autres environnements (développement, pré-production...).

L'accès aux environnements de production des composants classés critiques se fait au travers d'un bastion d'administration permettant d'ajouter les fonctions de sécurité suivantes :

▪ Traçabilité complète des opérations d'administration quel que soit le mode de connexion (mode commande, accès par bureau virtuel...)

▪ Renforcement du contrôle des actions d'administration (ex : blocage de certains droits de modification).

▪ Password safe permettant de ne pas utiliser directement les mots de passe des composants pour ceux en production.

▪ Il est recommandé de déployer, en plus du bastion, les bureaux virtuels (ex : VDI) associés à chaque profil administrateur pour assurer un meilleur contrôle du poste d'administrateur. Administration des environnements cloud.

L'accès aux interfaces d'administration des environnements déployés dans le Cloud doit respecter au moins les règles suivantes :

▪ Authentification forte systématique (MFA)
▪ Activation du plus haut niveau de traçabilité des opérations d'administration et exportation des traces vers un système de centralisation externe
▪ Renforcement de la surveillance de ces accès (par exemple, envoi d'un message d'alerte lors de la création d'un nouveau compte administrateur, lors de la connexion d'un nouveau poste client...).
▪ Filtrage lorsque cela est possible des adresses IP autorisées à se connecter à l'interface d'administration.

SF 9. Plan de reprise après sinistre
SF 9.1. Disponibilité et résilience
Storyfox a conçu des systèmes redondants pour que ses services continuent de fonctionner même si certaines parties de l'infrastructure sous-jacente connaissent des problèmes. Les services de Storyfox sont configurés de manière à résister aux pannes à long terme des serveurs individuels et des zones de disponibilité. Grâce à l'infrastructure AWS/OVH, toutes les données de Storyfox sont répliquées dans plusieurs régions géographiques afin de garantir un niveau élevé de durabilité en cas de catastrophe.

SF 9.2. Reprise après sinistre
Storyfox vise un objectif de point de récupération des données (RPO) de 3 heures pendant au moins 7 jours, et jusqu'à 24 heures au-delà de 7 jours. En raison de la nature distribuée des services de Storyfox, le RTO pour les désastres systémiques impliquant la récupération des données est ciblé à 8 heures.

SF 9.3. Notification et communication
Storyfox a établi des communications internes en utilisant les protocoles de sécurité standard de l'industrie afin que nos employés et la direction soient informés instantanément lors de tout événement d'urgence, ou lorsqu'un plan de récupération des données est initié ou désactivé.

SF 10. Annexe - Architecture serveur