1.  Introduction  

1. Objet 
‍
La présente politique de sécurité porte sur la solution STELLAR, outil GRC (Governance Risk and Compliance)mis à disposition par Systema Conseil à l’ensemble de ses clients pour notamment mettre en place et gérer leur SMSI (Système de Management de la Sécurité de l’Information).

Cette politique vise à établir un cadre pour assurer la confidentialité, l'intégrité, et la disponibilité des données traitées au sein de la solution STELLAR. 

2. Champ d’application 

La présente politique s’applique à toutes les informations de STELLAR, y compris les renseignements sur les clients, et les informations personnellement identifiables (IPI). Cette politique s’applique à l’ensemble de l’organisation Systema Conseil, y compris ses employés, entrepreneurs, sous-traitants, partenaires et toute personne qui crée, entretient, stocke, accède à, traite ou transmet des informations STTELAR. 

3. Objectifs de la sécurité des informations 

• Avoir en place un plan de sécurité des informations complet et à jour afin d’atténuer les risques liés à la sécurité des informations ;
• Prévenir les incidents en matière de sécurité le plus précocement possible et, s’ils se produisent, les détecter et les contenir au plus tôt ;
• Veiller à ce que tous les efforts de sécurité soient alignés sur les obligations de l’entreprise, ainsi que sur son rythme de croissance rapide ;• Tenir à jour une liste de toutes les ressources et des risques qui y sont associés. 

4. Organisation de la sécurité des informations 

Le CEO de Systema Conseil est responsable de la sécurité des informations de l’entreprise. Afin de fournir des conseils et d’appliquer une surveillance continue des pratiques de l’entreprise, les représentants suivants, au minimum, seront tenus d’organiser chaque mois une réunion du groupe chargé de la sécurité : 

• Directrice projet
• Responsable de la sécurité de systèmes d’information(RSSI)
• Responsable du service informatique 
‍
D’autres représentants des services de l’entreprise pourront se joindre au groupe au besoin. 

5. Gestion de la sécurité des informations 

Les employés, sous-traitants et tierces parties de Systema Conseil doivent se conformer aux politiques de l’entreprise. Leurs responsabilités doivent leur être communiquées dans le cadre de leur intégration à l’entreprise et sur une base régulière. Ils doivent en outre disposer d’un accès 24heures/24 et 7 jours/7 aux politiques. Toutes les politiques doivent être révisées au moins une fois par an. Les politiques applicables devront être examinées chaque fois qu’un changement majeur dans les pratiques de l’entreprise peut affecter la confidentialité, l’intégrité ou la disponibilité des données de l’entreprise ou de ses clients. Toutes les politiques doivent être approuvées par un membre de la direction.      

2. Rôles et responsabilités 

Les tâches et les domaines de responsabilités entrant en conflit doivent être séparés afin de réduire les possibilités de modification ou d’utilisation abusive non autorisée ou non intentionnelle des ressources de l’organisation. .

6. Équipe de direction 

L’équipe de direction a la responsabilité globale de s’assurer que l’engagement de l’entreprise envers cette politique est respecté. L’équipe de direction doit fournir les ressources nécessaires pour maintenir et améliorer le système de management de la sécurité de l’informations (SMSI) au sein de l’entreprise. L’équipe de direction est en chargé de définir la stratégie de sécurité de l’entreprise. 

7. Responsable de la sécurité des systèmes d'information (RSSI) 

Le RSSI est chargé de mettre en œuvre les processus et les contrôles de sécurité des informations ainsi que leur application.
Le RSSI rend compte à l’équipe de direction. Les principales responsabilités du RSSI sont les suivantes : 

• Chargé de la documentation du système de management de la sécurité des informations (SMSI).
• Évaluation périodique des risques dans le cadre de la politique de sécurité.
• Le cas échéant, recommandation des modifications à apporter aux politiques, aux normes et aux procédures.
• Vérification que tous les actifs critiques de l’entreprise sont sécurisés et contrôlés.
• Élaboration et application d’un programme d’éducation, de formation et de sensibilisation à la sécurité des informations.
• Recommandations concernant la conformité aux lois, aux règlements, aux meilleures pratiques et aux cadres. 

8. Responsable du service informatique 

Le responsable du service informatique est chargé de la mise en place des mesures de sécurité selon les politiques de sécurité approuves. Ses responsabilités sont les suivantes : 
‍
• Coordonner l’élaboration et la mise en œuvre de pratiques de gestion des informations, y compris les politiques, et les procédures ;
• Résoudre les problèmes de sécurité en cours soulevés parles employés, les fournisseurs, les partenaires et les clients de l’entreprise ;
• Coordonner et partager les informations parmi l’équipe SI afin d’assurer une exécution uniforme des activités de gestion de la sécurité des informations dans l’ensemble de l’organisation.

9. 2 Directrice projet

La directrice projet est responsable de coordonner le développement et la mise en œuvre des questionsde sécurité dans STELLAR.

10. Comité de direction en matière de sécurité

Le comité directeur en matière de sécurité est chargé d’examiner la planification stratégique en la matière et de l’approuver. Le comité directeur en matière de sécurité se réunira une fois par an. Les membres du comité directeur en matière de sécurité sont :

• CEO
• Directrice projet
• Responsable de la sécurité de systèmes d’information (RSSI)
• Responsable du service informatique

2.5. Collaborateurs

Tous les collaborateurs sont tenus de se conformer aux politiques et aux normes de sécurité desinformations de l’entreprise et doivent utiliser les ressources de cette dernière conformément à la charte informatique.

3. Mise en œuvre de la sécurité des informations
‍

11. Sécurité des ressources humaines

Les collaborateurs d’une entreprise sont l’une des ressources les plus précieuses dont elle dispose.
Les employés ont accès à des informations sensibles en raison de leur travail. La gestion sécurisée des ressources humaines de Systema Conseil est un élément essentiel de la sécurité globale de l’entreprise et est couverte par la Politique de sécurité des RH. Tous les collaborateurs signet dès lors arrivé :

• L’engagement de respect de la confidentialité des données. Clause dans le contrat de travail qui reste valable après leur départ.
• L’information RGPD concernant la collecte de ses données personnelles
• La charte informatique
• La charte administrateur pour les RH concernésUne procédure d'intégration et de départ des collaborateurs a été mis en place afin de faciliter le suivide l'attribution et du retour des actifs qui leur sont alloués dans le cadre de leur contrat, tels que l'accèset le matériel.

12. Sécurité de la gestion des ressources

Le manque de connaissances et de compétences en ce qui concerne les cibles d’une attaque dans une organisation présente un risque important. La cartographie des ressources d’une organisation et la définition des mesures pour les sécuriser diminuent considérablement le niveau de risque s’y rapportant.

• Toutes les ressources de l’entreprise (telles que les données, les logiciels, le matériel, etc.) seront comptabilisées et auront un titulaire ;
• Les titulaires de ressources seront identifiés pour chacune d’elles et seront responsables de l’entretien et de la protection de leurs ressources ;
• Toutes les informations doivent être classées et traitées selon leurs niveaux de sensibilité, comme indiqué dans la Politique de classification des données

Les données des clients stockées dans STTELAR sont classifiées avec le niveau de confidentialité le plus élevé, soit CONFIDENTIEL.

13. Contrôle d’accès

L’accès aux ressources est l’un des processus les plus sensibles d’une entreprise. Le fait de ne pas respecter les privilèges d’accès appropriés aux ressources peut exposer l’entreprise à un risque important. Dans Systema Conseil, les privilèges d’accès sont fournis selon les principes du besoin de savoir et du minimum de privilèges. Tous les aspects relatifs à la sécurité du contrôle d’accès sont détaillés dans la Politique du contrôle d’accès. Les collaborateurs de Systema Conseil n'ont pas accès aux environnements clients, sauf autorisation expresse du client pour effectuer les tâches demandées. Le client peut à tout moment révoquer l'accès aux données une fois la tâche finalisée. Les demandes d'autorisation doivent être envoyées àsupport@stellarsaas.com.

Voici une liste non exhaustive des tâches :

• Importation des données,
• Vérification d'un bug non reproductible dans les environnements de test,• Restitution de la donnée,
• Configuration de la solution,
•….Le choix des méthodes et des mécanismes d’authentification est sous la responsabilité du client.

Toutefois le personnel Systema Conseil en charge de la conception applications se doit de rappeler et conseiller le client des bonnes pratiques.
Documentation complémentaire : https://www.ssi.gouv.fr/guide/mot-de passe/
https://www.ssi.gouv.fr/administration/precautions-elementaires/calculer-la-force-dun-mot-depass

14. Cryptographie

Systema Conseil gère des informations sensibles au nom de ses clients, en plus de celles relatives à ses opérations internes. Le chiffrement de ces données en transit (lorsqu’elles sont envoyées d’un composant à un autre) et au repos (lorsqu’elles sont stockées) est d’une importance cruciale. Les contrôles de sécurité cryptographiques de Systema Conseil sont détaillés dans la Politique d’utilisation des mesures de chiffrement.

Chiffrement en place dans STELLAR :

• Chiffrement des connexions TLS 1.2/1.3.
• Chiffrement des mots de passes utilisateurs en bases de données
• Les disques des serveurs de sauvegarde sont également chiffrés.
• Les archives sont chiffrées sur le serveur de backup.

15. Sécurité physique et environnementale

La sécurité physique et environnementale fait référence aux mesures que Systema Conseil utilise pour sécuriser ses locaux et ses ressources. Elle est détaillée dans la Politique de sécurité physique et environnementale. Aucune donnée des clients n'est physiquement stockée sur les locaux.

16. Gestion des vulnérabilités

Des normes et procédures sont établis pour mettre en place une gestion des vulnérabilités techniques et des risques associés pour ce qui est des moyens de production mis en œuvre et des résultats produits par les activités de développement
‍
i. Généralités

Les tests de vulnérabilité doivent être régulièrement exécutés par des ressources internes et externes. Des sources d’information externes doivent être utilisées pour se tenir au courant des vulnérabilités des logiciels. Les vulnérabilités doivent être enregistrées et un propriétaire doit être assigné. Le propriétaire doit définir la méthode et les délais de résolution. Tous les clients potentiels concernés doivent être informés. Toute vulnérabilité identifiée doit être résolue dans les 30 jours suivant la date à laquelle elle a été identifiée. Une fois que le système affecté a été corrigé, le même test qui a identifié à l’origine la vulnérabilité doit être effectué à nouveau pour s’assurer que le problème est résolu.

ii. Codes sources

iii. Code produit

Le code est contrôlé pour détecter les vulnérabilités qui pourraient être introduites lors des phases de développement. Ces contrôles sont intégrés au processus de développement. Ils conditionnent l’acceptation des MR (merge request) : une alerte doit bloquer la MR. Le refus ou l’acceptation de la MR est sous la responsabilité du Lead Developper en charge de traiter la MR.Toute alerte issue d’un contrôle du code source doit être traitée soit en corrigeant le code incriminé, soit par justification.

iv. Relecture de code

Un premier type de contrôle est réalisé par relecture de code. Le Lead Developper ou le développeur détecte que le code qu’il modifie ou produit est sensible (écriture ou lecture en base ou fichiers, manipulation de données sensibles, etc.). Il demande une relecture par un tiers. Cette relecture identifie les vulnérabilités introduites ou pressenties dans le code.

v. Code intégré

Le framework intègre des bibliothèques externes, celles-ci sont soit livrées avec les paquets soit utilisées lors de la génération de certaines parties de code. Les bibliothèques sont auditées lors de plusieurs étapes du cycle de vie de l’application :

• Tous les jours à heure fixe,
• A chaque demande d’ajout de code dans la base commune.Les outils d’audit cherchent les CVE connues sur les bibliothèques et les remontent par mail.

vi. Installations OS et application

Les serveurs de production sont équipés de versions bénéficiant d'un support actif. Les systèmes d'exploitation des serveurs sont mis à jour conformément aux versions fournies par le fabricant.

vii. Gestion des alertes sécurités

Une veille est réalisée et permet de prendre en compte les alertes sécurité.Dans le cas des alertes sur le OS, le processus est simplifié pour améliorer l’efficacité du service. Une analyse de l’alerte est faite et la mise à jour est réalisé en fonction des contraintes de services, dans undélai de 10 jours maximum.

17. Journalisation

Une politique de journalisation est établie pour tous les composants du SI (serveurs et applications) mis en œuvre pour les assurer les activités de production. Cette politique décrit les normes et procédures permettant de mettre en place une gestion de la journalisation du SI et l’exploitation de ces journaux dans le cadre de la politique de sécurité du système d’information.

viii. Enregistrement des journaux

ix. Synchronisation des horloges

Une source de temps unique est mise en œuvre pour l’ensemble du SI, ainsi :

• L’horodatage doit être activé pour l’ensemble des évènements afin de permettre une meilleure exploitation des journaux.
• Les systèmes d’information et équipements doivent être synchronisés sur cette source de tempsunique au sein de l’entreprise pour pouvoir analyser convenablement les journaux collectés.

x. Résilience du système de journalisation

Une architecture de journalisation efficace et sécurisée est mise en œuvre :
• Les journaux sont enregistrés localement sur le système les produisant ;
• Les journaux sont transférés en temps réel (SYSLOG) vers le serveur de journalisation ;
• Les journaux sont transférés sans avoir subi de traitement ;
• Le serveur de centralisation est backupé conformément à la politique de sauvegarde.

xi. Stockage des journaux

Afin d’éviter la saturation des disques des équipements qui produisent ou centralisent des journaux, les taux d’occupation des disques stockant les journaux sont surveillés et des alertes remontées.

xii. Durée de rétention
‍
• Les journaux sont conservés sur une période de 1 an.

xiii. Protection des journaux

Les journaux doivent être protégés contre tout risque de falsification et d’accès non autorisé :
‍
• L’accès aux journaux doit être limité en écriture à un nombre restreint de comptes ayant le besoin d’en connaître.
• Les processus de journalisation et de collecte doivent être exécutés par des comptes disposant de peu privilèges.

18. Gestion des incidents affectant la sécurité des informations

Systema Conseil déploie des efforts substantiels pour prévenir tout incident pouvant avoir un impact sur la confidentialité, la disponibilité et l’intégrité des données que l’entreprise traite au nom de ses clients. Malgré cela, il n’est pas possible d’atténuer pleinement le risque d’incidents. En cas d’incident lié à la sécurité des informations, Systema Conseil le détectera et le contiendra dans les délais les plus courts possible. Tous les aspects de la gestion des incidents liés à la sécurité des informations sont traités dans la Procédure de réponse aux incidents, le plan de reprise après sinistre et le plan de continuité des activités.

xiv. Violation de Données Personnelles

Systema Conseil s’engage à informer le client de toute Violation de Données Personnelles et à apporter son concours à toute demande du client et à la mise en œuvre de toute mesure permettant d’y remédier. Dans ces cas, Systema Conseil s’engage à :
‍
• Informer le client dans les meilleurs délais, et au maximum sous 48 heures, après avoir connaissance de la Violation ;
• Apporter tout élément nécessaire au client pour évaluer les risques et impacts de cette Violation et lui permettant de prendre toutes décisions et mesures utiles quant à sa gestion et suites à donner ;
• Fournir les éléments de précisions suivants pour toute Violation et a minima : nature de laViolation, catégorie et nombre approximatif de personnes concernées ou susceptibles de l’être, catégories et volume des données Personnelles impactées, conséquences probables de la Violation des Données Personnelles, évaluation des préjudices potentiels et niveau de gravité, mesures techniques et organisationnelles déjà prises ou proposées pour y remédier.

xv. Signalement des incidents

Tous les utilisateurs de STELLAR peuvent signaler les incidents via l’adresse email support@stellarsaas.com.

xvi. Traitement des incidents

Le traitement des incidents couvre le fonctionnement de la solution STELLAR. Le traitement des incidents couvre :

• Les incidents liés à l’infrastructure,
• Les incidents liés à une anomalie avérée STELLAR. Toute autre demande, notamment lié à une anomalie applicative liée à un défaut de paramétrage par le client est traitée dans le cadre des demandes d’accompagnement.

xvii. Classification des incidents

Les incidents sont catégorisés selon leur niveau d’impact :• Incident bloquant : La solution est inutilisable ;• Incident majeur : La solution est partiellement utilisable mais présente des dysfonctionnements• Incident mineur : caractérise tout incident ni bloquant, ni majeur

xviii. Processus de demande

Le processus suivant décrit les étapes dans l’ordre chronologique :

• Le client dépose sa demande et la caractérise, le client et Systema Conseil précisent et formalisent de la demande le cas échéant ;
• Systema Conseil prend en charge de la demande dans le délai contractuel, et indique une solution proposée, un délai de correction ;
• Client donne son accord pour le traitement de la demande ;
• Systema Conseil réalise la demande ;
• Client clos la demande.
• Le cas échéant, le traitement de l’incident inclus une restauration des dernières données sauvegardées.

19. Développement sécurisé

La solution STELLAR traitent des données sensibles et critiques pour le compte de ses clients. Les services devraient donc être mis en place selon les normes de sécurité les plus élevées, afin d’assurer la confidentialité, la disponibilité et l’intégrité des informations.

xix. Contrôle du code source

• Tout le code source est stocké dans un référentiel de code.
• Les changements de code ne doivent pas être poussés directement vers la branche de développement principale.
• Le code doit être examiné par un pair avant de pouvoir être validé pour l’acceptation.
• L’accès au code source est accordé selon le principe du moindre privilège, conformément à la politique de contrôle d’accès.
• Les secrets, tels que les mots de passe, les clés d’accès, les clés privées SSH, ne doivent pas être validés dans les référentiels de code source.

xx. Développement

• Chaque demande d’amélioration défini ses critères d’acceptation.
• La confidentialité, la sécurité et les tests font partie de toute conception.
• Les développeurs doivent être conscients des menaces et vulnérabilités courantes (par le biais d’initiatives telles que https://owasp.org/).
• Les bugs impliquant la sécurité, l’intégrité de données et la criticité pour les clients sont prioritaires sur les nouvelles fonctionnalités.

xxi. Bibliothèques et frameworks

L’utilisation de bibliothèques et de frameworks est encouragée, avec les dispositions suivantes :
‍
• Les versions doivent être épinglées, pour garantir des builds reproductibles et aider à évaluer l’impact des vulnérabilités
• La dernière version stable doit être privilégiée, sinon une évaluation de la vulnérabilité doit être effectuée et des mesures d’atténuation prises
• La conformité des licences doit être vérifiée
• Les changements (« forks ») doivent être clairement identifiés comme tels (par exemple, modifier le nom de la bibliothèque)
• La maturité ET le maintien doivent être évalués
• Les bibliothèques/frameworks non maintenus ou immatures doivent être évités
• Tout ajout d’une nouvelle bibliothèque doit être motivé.

20. Hébergement
‍
• Les hébergements sont faits sur les infrastructures OVH Openstack, en France.
• Les backups sont faits sur les infrastructures Scaleway, en France.
• Tous les environnements STELLAR clients sont isolés entre eux, chacun a sa propre base de données..

21. Disponibilité de l’infrastructure

Systema Conseil garantit une disponibilité de l’infrastructure supérieure ou égale à 98% de chaque période Annuelle, en dehors d’un temps de maintenance planifié avec le Client et hors cas de force majeure.

22. Sauvegardes et restauration

• Une sauvegarde des données (base de données + fichiers) est faite toutes les nuits en local ;
• Les éléments sauvegardés en local sont ensuite téléversés dans un dépôt Restic(https://restic.net) chiffré sur un Object Storage S3 privé chez OVH ;
• Sur ce dépôt Restic ne sont conservés que les 7 dernières sauvegardes (7 derniers jours).
• Tous les week-end (nuit du samedi au dimanche), le dépôt Restic chiffré est exporté sur un serveur dédié chez Scaleway sur une partition elle-même chiffrée.
• Le dépot Restic écrase le dépôt précédent.
• Les sauvegardes sont testées tous les trimestres en tentant une restauration complète sur un système différent et isolé (pour éviter l'exposition des données de production).

23. Conformité

Systema Conseil s’engage à respecter toutes les lois, réglementations et normes applicables. Pour ce faire, il convient de prendre continuellement connaissance de nouvelles lois, de nouvelles réglementations et de la publication de nouvelles normes, tant au niveau local qu’international.