La sécurisation du code est un aspect crucial du développement de logiciels et chez Cybernetics nous prenons cela très au sérieux. Serenetics respecte une sécurité dès conception (security by design).
VALIDATION DES ENTRÉES
Les différentes entrées renseignées par les utilisateurs sont contrôlées par Serenetics.
1.1 Effectuer la validation de toutes les données sur un système fiable
Effectuer la validation de toutes les données sur un système fiable.
Les données sont validées sur une API dédiée : https://api.serenetics.app
1.2 Identifier toutes les sources de données et les classer en fiables et non fiables
Identifier toutes les sources de données et les classer en fiables et non fiables. Valider toutes les données provenant de sources non fiables.
Les données provenant de services tiers ne font pas l’objet de validation.
1.3 Valider toutes les données provenant de sources non fiables
Identifier toutes les données provenant de sources non fiables.
Les données provenant de services tiers ne font pas l’objet de validation.
1.4 Il doit y avoir une routine centralisée de validation des entrées pour l'application
Il doit y avoir une routine centralisée de validation des entrées pour l'application.
Serenetics dispose d'un support de premier ordre pour l'analyse et la validation des entrées utilisateurs. Un schéma de validation doit être défini et utilisé afin de valider les entrées. Le schéma définit le nom des entrées, le type et les règles attendues.
1.5 Spécifier les jeux de caractères appropriés, tels que UTF-8, pour toutes les sources d'entrées
Spécifier les jeux de caractères appropriés, tels que UTF-8, pour toutes les sources d'entrées.
Serenetics suit la norme UTF-8.
1.6 Encoder les données dans un jeu de caractères commun avant de valider
Encoder les données dans un jeu de caractères commun avant de valider (canonicalize).
Serenetics encode les données en UTF-8.
1.7 Tous les échecs de validation devraient entrainer le rejet de l'entrée
Tous les échecs de validation devraient entrainer le rejet de l'entrée.
Lorsque la validation échoue, une réponse en erreur est systématiquement retournée au client (Erreur 422 : Unprocessable Entity).
1.8 Vérifier si le système prend en charge les jeux de caractères étendus UTF-8 et les valide une fois le décodage UTF-8 terminé
Vérifier si le système prend en charge les jeux de caractères étendus UTF-8 et les valide une fois le décodage UTF-8 terminé.
1.9 Valider toutes les données fournies par le client avant le traitement
Valider toutes les données fournies par le client avant le traitement.
1.10 Vérifier que les valeurs d'en-tête de protocole dans les requêtes et les réponses contiennent uniquement des caractères ASCII
Vérifier que les valeurs d'en-tête de protocole dans les requêtes et les réponses contiennent uniquement des caractères ASCII.
Serenetics s'assure que les en-têtes ont uniquement des caractères ASCII.
1.11 Valider les données des redirections
Valider les données des redirections.
Serenetics ne fait aucune redirection.
1.12 Valider les types de données attendus en utilisant une liste « autoriser » plutôt qu'une liste « refuser »
Valider les types de données attendus en utilisant une liste « autoriser » plutôt qu'une liste « refuser ».
Le contrôle du type des entrées est faite au sein des validateurs. Certaines règles déterminent une liste blanche de caractères autorisés ou de valeurs attendues.
1.13 Valider la plage de données
Valider la plage de données.
La plage de donnée est validée au sein des validateurs grâce aux règles.
1.14 Valider la longueur des données
Valider la longueur des données.
La longueur des données est validée au sein des validateurs grâce aux règles. La longueur suit la limite définie en base de données.
1.15 Si une entrée potentiellement dangereuse doit être autorisée, mettre en œuvre des contrôles supplémentaires
Si une entrée potentiellement dangereuse doit être autorisée, mettre en œuvre des contrôles supplémentaires.
Nous utilisons des règles permettant de nettoyer les données et échapper les caractères susceptibles de porter atteintes au fonctionnement normal de l'application.
1.16 Si la routine de validation standard ne peut pas traiter certaines entrées, utiliser des contrôles discrets supplémentaires
Si la routine de validation standard ne peut pas traiter certaines entrées, utiliser des contrôles discrets supplémentaires.
Lorsque le validateur ne suffit pas au contrôle des entrées, la validation est fait au sein du contrôleur qui est en charge de traiter la demande.
1.17 Utiliser la canonisation pour répondre aux attaques d'obscurcissement
Utiliser la canonisation pour répondre aux attaques d'obscurcissement.
ENCODAGE DE SORTIE
Les différentes sorties renseignées sont contrôlées par Serenetics.
2.1 Effectuer tout le codage sur un système de confiance
Effectuer tout le codage sur un système de confiance.
Tout est effectué sur un serveur dédié : https://api.serenetics.app
2.2 Utiliser une routine standard testée pour chaque type d'encodage sortant
Utiliser une routine standard testée pour chaque type d'encodage sortant.
Serenetics fournit des réponses standards encodées en UTF-8.
2.3 Spécifier des jeux de caractères, tels que UTF-8, pour toutes les sorties
Spécifiez des jeux de caractères, tels que UTF-8, pour toutes les sorties.
Serenetics fournit des réponses standards encodées en UTF-8.
2.4 La sortie contextuelle encode toutes les données renvoyées au client à partir de sources non fiables
La sortie contextuelle encode toutes les données renvoyées au client à partir de sources non fiables.
Toutes les données sont traitées/nettoyées avant d'être affichées au client.
2.5 S'assurer que le codage de sortie est sûr pour tous les systèmes cibles
S'assurer que le codage de sortie est sûr pour tous les systèmes cibles.
L'encodage en sortie est en UTF-8, le standard universel actuel.
2.6 Nettoyer contextuellement toutes les sorties de données non fiables dans les requêtes SQL, XML et LDAP
Pour toutes les requêtes SQL, l'ORM nous assure un nettoyage des donnée avant stockage en base de donnée. Nous n'avons pas de requête XML et LDAP pour l'application.
Pour toutes les requêtes SQL, l'ORM que nous utilisons nous assure un nettoyage des donnée avant stockage en base de données. Nous n'avons pas de requête XML et LDAP pour l'application.
2.7 Nettoyer toutes les sorties de données non fiables vers les commandes du système d'exploitation
Nettoyer toutes les sorties de données non fiables vers les commandes du système d'exploitation.
AUTHENTIFICATION ET GESTION DES MOTS DE PASSE
La gestion de l'authentification est contrôlée par Serenetics.
3.1 Exiger une authentification pour toutes les pages et ressources sauf celles spécifiquement destinées à être publiques
Exiger une authentification pour toutes les pages et ressources sauf celles spécifiquement destinées à être publiques.
Toutes les pages et ressources requièrent une authentification hormis pour les pages et ressources relatives au mécanisme d’authentification (page de connexion, d’enregistrement, etc.).
3.2 Tous les contrôles d'authentification doivent être appliqués sur un système de confiance
Tous les contrôles d'authentification doivent être appliqués sur un système de confiance.
Toutes les vérifications pour l’authentification sont faites sur un serveur dédié : https://api.serenetics.app
3.3 Établir et utiliser des services d'authentification standard et testés dans la mesure du possible
Établir et utiliser des services d'authentification standard et testés dans la mesure du possible.
Nous avons mis en place plusieurs manières de s’authentifier :
Authentification classique, via un courriel et un mot de passe.
Authentification via le système Oauth (Open Authorization).
Un système d’authentification à double facteur.
Le système d'authentification est testé au travers de multiple recettes.
3.4 UtiliseR une implémentation centralisée pour tous les contrôles d'authentification, y compris les bibliothèques qui appellent des services d'authentification externes
UtiliseR une implémentation centralisée pour tous les contrôles d'authentification, y compris les bibliothèques qui appellent des services d'authentification externes.
Le système d’authentification classique est défini dans un contrôleur dédié.
Le système d’authentification via OAuth est centralisé grâce à l’implémentation fournie par Serenetics.
3.5 Séparer la logique d'authentification de la ressource demandée et utiliser la redirection vers et depuis le contrôle d'authentification centralisé
Séparer la logique d'authentification de la ressource demandée et utiliser la redirection vers et depuis le contrôle d'authentification centralisé.
La logique d'authentification est séparée de toute ressource. Si l'accès a une ressource requérant l'authentification est demandée, alors l'utilisateur est notifié de l'interdiction et il est reconduit sur la page de login.
3.6 Tous les contrôles d'authentification devraient échouer en toute sécurité
Tous les contrôles d'authentification devraient échouer en toute sécurité.
L’algorithme pour l’authentification suit le principe de moindre privilège et n’autorise l’utilisateur que s’il répond à toutes les conditions requises.
3.7 Toutes les fonctions administratives et de gestion de compte doivent être au moins aussi sécurisées que le mécanisme d'authentification principal
Toutes les fonctions administratives et de gestion de compte doivent être au moins aussi sécurisées que le mécanisme d'authentification principal.
Elles sont soumises également au principe de moindre privilège.
3.8 Si l'application gère un magasin d'informations d'identification, utiliser des hachages salés unidirectionnels cryptographiquement forts
Si l'application gère un magasin d'informations d'identification, utiliser des hachages salés unidirectionnels cryptographiquement forts.
Les mots de passe sont haché grâce à une fonction de dérivation forte et recommandée avant d’être stockés en base de données.
3.9 Le hachage du mot de passe doit être implémenté côté serveur d'un système de confiance et non côté client
Le hachage du mot de passe doit être implémenté côté serveur d'un système de confiance et non côté client.
Le mot de passe est haché sur un serveur dédié à l’application, https://api.serenetics.app
3.10 Valider les données d'authentification uniquement à la fin de toutes les saisies de données
Valider les données d'authentification uniquement à la fin de toutes les saisies de données.
Les données d'authentification sont vérifiées uniquement lorsque toutes les informations sont saisies.
3.11 Les réponses aux échecs d'authentification ne doivent pas indiquer quelle partie des données d'authentification était incorrecte
Les réponses aux échecs d'authentification ne doivent pas indiquer quelle partie des données d'authentification était incorrecte.
Lorsque l’authentification échoue, l’exception BadCredential est levée. Elle ne renseigne pas précisément la raison.
3.12 Utiliser l'authentification pour les connexions à des systèmes externes impliquant des informations ou des fonctions sensibles
Utiliser l'authentification pour les connexions à des systèmes externes impliquant des informations ou des fonctions sensibles.
L'utilisateur doit obligatoirement être connecté avant la transmission d'information relative à ses données d'identification à des services externes.
3.13 Les informations d'authentification pour accéder aux services externes à l'application doivent être stockées dans un magasin sécurisé
Les informations d'authentification pour accéder aux services externes à l'application doivent être stockées dans un magasin sécurisé.
Pour l’accès aux services externes, les identifiants de connexion sont chiffrés avant d’être stockés en base de données dédiée à l’application.
3.14 Utiliser uniquement les requêtes http post pour transmettre les identifiants d'authentification
Utiliser uniquement les requêtes http post pour transmettre les identifiants d'authentification.
Seule la méthode post est utilisée pour le transfert des données relatives à l’authentification à l’application.
3.15 Envoyez uniquement des mots de passe non temporaires via une connexion cryptée ou sous forme de données cryptées
Envoyez uniquement des mots de passe non temporaires via une connexion cryptée ou sous forme de données cryptées.
L’application est déployée sur un environnement utilisant le protocole TSL . Toutes les informations sont chiffrées. Les courriels ne contiennent pas de mot de passe non temporaire.
3.16 Appliquer les exigences en matière de complexité des mots de passe établies par la politique ou la réglementation
Appliquer les exigences en matière de complexité des mots de passe établies par la politique ou la réglementation.
Le mot de passe doit être composé d'au moins une lettre majuscule, une lettre minuscule, un chiffre et un caractère spécial. Un minimum de 16 caractères est demandé.
3.17 Appliquer les exigences en matière de longueur de mot de passe établies par la politique ou la réglementation
Appliquer les exigences en matière de longueur de mot de passe établies par la politique ou la réglementation.
Le mot de passe doit être composé d'au moins 16 caractères.
3.18 La saisie du mot de passe doit être masquée sur l'écran de l'utilisateur
La saisie du mot de passe doit être masquée sur l'écran de l'utilisateur.
La saisie du mot de passe est masquée sur l’interface.
3.19 Appliquer la désactivation du compte après un nombre établi de tentatives de connexion invalides
Appliquer la désactivation du compte après un nombre établi de tentatives de connexion invalides.
Le compte est désactivé au bout de 5 tentatives infructueuses et pour une durée de 5 minutes.
3.20 Les opérations de réinitialisation et de modification de mot de passe nécessitent le même niveau de contrôle que la création et l'authentification de compte
Les opérations de réinitialisation et de modification de mot de passe nécessitent le même niveau de contrôle que la création et l'authentification de compte.
Elles sont soumises également au principe de moindre privilège.
3.21 Les questions de réinitialisation du mot de passe doivent prendre en charge des réponses suffisamment aléatoires
Les questions de réinitialisation du mot de passe doivent prendre en charge des réponses suffisamment aléatoires.
Nous n’utilisons pas de tel système pour la réinitialisation du mot de passe.
3.22 Si des réinitialisations par courrier électronique sont mises en place, envoyer uniquement un courrier électronique à une adresse pré-enregistrée avec un lien/mot de passe temporaire
Si des réinitialisations par courrier électronique sont mises en place, envoyer uniquement un courrier électronique à une adresse pré-enregistrée avec un lien/mot de passe temporaire.
Nous utilisons belle et bien des réinitialisations de mot de passe par email. L’email fourni une URL signée permettant l’accès à une page sécurisée permettant la réinitialisation du mot de passe.
3.23 Les mots de passe et les liens temporaires devraient avoir un temps d'expiration court
Les mots de passe et les liens temporaires devraient avoir un temps d'expiration court.
Les liens signés expirent au bout de quelques minutes :
10 minutes pour le lien permettant l’accès à la page de changement de mot de passe.
2 minutes pour le lien permettant le changement de mot de passe.
3.24 Imposer le changement du mot de passe temporaire au prochain usage
Appliquer le changement des mots de passe temporaires lors de la prochaine utilisation.
L’utilisateur est forcé de changer son mot de passe lors de la première connexion. S’il n’a pas fait la modification de son mot de passe, l’accès aux ressources lui sera refusé.
3.25 Avertir les utilisateurs lorsqu'une réinitialisation de mot de passe se produit
Avertir les utilisateurs lorsqu'une réinitialisation de mot de passe se produit.
Un mail est envoyé à l’utilisateur dès qu’il y a une modification de son mot de passe.
3.26 Empêcher la réutilisation des mots de passe
Empêcher la réutilisation des mots de passe.
Une restriction lors de la phase du changement de mot de passe permet de s’assurer que l’utilisateur ne peut pas définir le mot de passe utilisé actuellement comme nouveau mot de passe.
3.27 Les mots de passe doivent dater d'au moins un jour avant de pouvoir être modifiés, afin d'éviter les attaques liées à la réutilisation des mots de passe
Les mots de passe doivent dater d'au moins un jour avant de pouvoir être modifiés, afin d'éviter les attaques liées à la réutilisation des mots de passe.
3.28 Appliquer les changements de mot de passe en fonction des exigences établies dans la politique ou la réglementation, avec le temps entre les réinitialisations contrôlé administrativement
Appliquer les changements de mot de passe en fonction des exigences établies dans la politique ou la réglementation, avec le temps entre les réinitialisations contrôlé administrativement.
3.29 Désactivez la fonctionnalité « Se souvenir de moi » pour les champs de mot de passe
Désactivez la fonctionnalité « Se souvenir de moi » pour les champs de mot de passe.
Serenetics à fait le choix de ne pas désactiver le champ "se souvenir de moi".
3.30 La dernière utilisation (réussie ou non) d'un compte utilisateur doit être signalée à l'utilisateur lors de sa prochaine connexion réussie
La dernière utilisation (réussie ou non) d'un compte utilisateur doit être signalée à l'utilisateur lors de sa prochaine connexion réussie.
3.31 Mettre en œuvre une surveillance pour identifier les attaques contre plusieurs comptes d'utilisateurs, en utilisant le même mot de passe
Mettre en œuvre une surveillance pour identifier les attaques contre plusieurs comptes d'utilisateurs, en utilisant le même mot de passe.
3.32 Modifier tous les mots de passe et identifiants utilisateur par défaut fournis par le fournisseur ou désactiver les comptes associés
Modifier tous les mots de passe et identifiants utilisateur par défaut fournis par le fournisseur ou désactiver les comptes associés.
Serenetics n'est pas concerné puisqu'il gère les mots de passe de bout en bout.
3.33 Réauthentifier les utilisateurs avant d'effectuer des opérations critiques
Réauthentifier les utilisateurs avant d'effectuer des opérations critiques.
3.34 Utiliser l'authentification multifacteur pour les comptes transactionnels très sensibles ou de haute valeur
Utiliser l'authentification multifacteur pour les comptes transactionnels très sensibles ou de haute valeur.
Un système d’authentification à double facteur a été mis en place pour plus de sécurité. Il est obligatoire pour tous les utilisateurs souhaitant utiliser l’application.
3.35 Si un code tiers est utilisé pour l'authentification, inspecter attentivement le code pour s'assurer qu'il n'est pas affecté par un code malveillant
Si un code tiers est utilisé pour l'authentification, inspectez attentivement le code pour s'assurer qu'il n'est pas affecté par un code malveillant.
L’authentification est gérée par notre framework et cela assure une authentification sécurisée. Nous veillons à ce qu'on les paquet soit mis a jours et que le code n'est pas affecté par un code malveillant.
GESTION DES SESSIONS
La gestion des sessions est contrôlée par Serenetics.
4.1 Utiliser les commandes de gestion de session du serveur ou du framework. L'application doit uniquement reconnaître ces identifiants de session comme valables
Utiliser les commandes de gestion de session du serveur ou du framework. L'application doit uniquement reconnaître ces identifiants de session comme valables.
Nous utilisons le système de session mis en place par le framework. Il établit le contrôle via l’identifiant de la session.
4.2 La création de l'identifiant de session doit toujours être effectuée sur un système de confiance (côté serveur et non côté client)
La création d'un identifiant de session doit toujours être effectuée sur un système de confiance (côté serveur et non côté client).
La vérification est faite sur notre serveur dédié à l’application, https://api.serenetics.app
4.3 Les contrôles de gestion de session doivent utiliser des algorithmes bien vérifiés qui garantissent des identifiants de session suffisamment aléatoires
Les contrôles de gestion de session doivent utiliser des algorithmes bien vérifiés qui garantissent des identifiants de session suffisamment aléatoires.
4.4 Définir le domaine et le chemin des cookies contenant des identifiants de session authentifiés sur une valeur restreinte appropriée pour le site
Définir le domaine et le chemin des cookies contenant des identifiants de session authentifiés sur une valeur restreinte appropriée pour le site.
Serenetics implémente l'option du cookie avec le paramètre "SameSite:true". Il ne sera envoyé que si la demande provient du même site.
4.5 La fonctionnalité de déconnexion doit mettre fin complètement à la session ou à la connexion associée
La fonctionnalité de déconnexion doit mettre fin complètement à la session ou à la connexion associée.
La session se termine complètement suite à la procédure dédiée à la déconnexion.
4.6 La fonctionnalité de déconnexion doit être disponible sur toutes les pages protégées par autorisation
La fonctionnalité de déconnexion doit être disponible sur toutes les pages protégées par autorisation.
Les pages protégées par autorisation ont toutes la fonctionnalité de déconnexion.
4.7 Établir un délai d'inactivité de session aussi court que possible, en fonction de l'équilibre entre les risques et les exigences fonctionnelles de l'entreprise
Établir un délai d'inactivité de session aussi court que possible, en fonction de l'équilibre entre les risques et les exigences fonctionnelles de l'entreprise.
Les cookies pour la session expire en 2h.
4.8 Interdire les connexions persistantes et imposer des fermetures de session périodiques, même lorsque la session est active
Interdire les connexions persistantes et imposer des fermetures de session périodiques, même lorsque la session est active.
4.9 Si une session a été établie avant la connexion, fermer cette session et établir une nouvelle session après une connexion réussie
Si une session a été établie avant la connexion, fermer cette session et établir une nouvelle session après une connexion réussie.
4.10 Générer un nouvel identifiant de session à toute ré-authentification
Générer un nouvel identifiant de session à toute ré-authentification.
Serenetics génère un nouvel identifiant de session à toute ré-authentification.
4.11 Ne pas autoriser les connexions simultanées avec le même ID utilisateur
Ne pas autoriser les connexions simultanées avec le même ID utilisateur.
4.12 Ne pas exposer les identifiants de session dans les URL, les messages d'erreur ou les journaux
Ne pas exposer les identifiants de session dans les URL, les messages d'erreur ou les journaux.
L’identifiant de la session est chiffré avant d’être transféré au client. L’information n’est stockée que dans les cookies.
4.13 Mettre en œuvre des contrôles d'accès appropriés pour protéger les données de session côté serveur contre tout accès non autorisé d'autres utilisateurs du serveur
Mettre en œuvre des contrôles d'accès appropriés pour protéger les données de session côté serveur contre tout accès non autorisé d'autres utilisateurs du serveur.
Serenetics assure le contrôle d'accès avec la conteneurisation et protège les session coté serveur contre tout accès non autorisé d'autres utilisateurs du serveur.
4.14 Générer un nouvel identifiant de session et désactiver périodiquement l'ancien
Générer un nouvel identifiant de session et désactiver périodiquement l'ancien.
4.15 Générer un nouvel identifiant de session si la sécurité de la connexion passe de HTTP à HTTPS, comme cela peut se produire lors de l'authentification
Générer un nouvel identifiant de session si la sécurité de la connexion passe de HTTP à HTTPS, comme cela peut se produire lors de l'authentification.
Serenetics transmet directement l'identifiant de session en https, sans bascule http.
4.16 Utiliser systématiquement HTTPS plutôt que de basculer entre HTTP et HTTPS
Utiliser systématiquement HTTPS plutôt que de basculer entre HTTP et HTTPS.
4.17 Compléter la gestion de session standard pour les opérations sensibles côté serveur, comme la gestion des comptes, en utilisant des jetons ou des paramètres aléatoires forts par session
Compléter la gestion de session standard pour les opérations sensibles côté serveur, comme la gestion des comptes, en utilisant des jetons ou des paramètres aléatoires forts par session.
4.18 Compléter la gestion de session standard pour les opérations hautement sensibles ou critiques en utilisant par requête, plutôt que par session, des jetons ou des paramètres aléatoires forts
Compléter la gestion de session standard pour les opérations hautement sensibles ou critiques en utilisant par requête, plutôt que par session, des jetons ou des paramètres aléatoires fort.
4.19 Définir l'attribut « sécurisé » pour les cookies transmis sur une connexion TLS
Définir l'attribut « sécurisé » pour les cookies transmis sur une connexion TLS.
Serenetics à défini les attribut sécurisé "secure:true" pour les cookies transmis.
4.20 Définir des cookies avec l'attribut HttpOnly, sauf si des scripts côté client sont spécifiquement nécessaires dans votre application pour lire ou définir la valeur d'un cookie
Définir des cookies avec l'attribut HttpOnly, sauf si des scripts côté client sont spécifiquement nécessaires dans votre application pour lire ou définir la valeur d'un cookie.
Serenetics à défini l'attribut "HttpOnly" pour les cookies.
4.21 Protéger les données de session côté serveur contre l'accès non autorisé par d'autres utilisateurs du serveur, en implémentant des contrôles d'accès appropriés sur le serveur
Protéger les données de session côté serveur contre l'accès non autorisé par d'autres utilisateurs du serveur, en implémentant des contrôles d'accès appropriés sur le serveur.
Serenetics assure que les données de session ne sont pas stockée côté server. Des stratégies permettent d’identifier si l’utilisateur demandeur a le droit d'accès à la ressource concernée.
CONTROLE D'ACCÈS
5.1 Utiliser uniquement des objets système de confiance, par exemple objets de session côté serveur, pour prendre des décisions d'autorisation d'accès
Utiliser uniquement des objets système de confiance, par exemple objets de session côté serveur, pour prendre des décisions d'autorisation d'accès.
Serenetics est en charge de valider les autorisations d'accès. L'identification de l'utilisateur est basée sur un cookie chiffré de manière sécurisé.
5.2 Utiliser un seul composant à l’échelle du site pour vérifier l’autorisation d’accès. Cela inclut les bibliothèques qui appellent des services d'autorisation externes
Utiliser un seul composant à l’échelle du site pour vérifier l’autorisation d’accès. Cela inclut les bibliothèques qui appellent des services d'autorisation externes.
Serenetics utilise le package fourni par son framework pour le contrôle d'accès et qui vérifie l'authentification.
5.3 Les contrôles d'accès devraient échouer en toute sécurité
Les contrôles d'accès devraient échouer en toute sécurité.
Lorsque l’accès n’est pas permis, une exception est lancée. Le retour client est de type 403, Forbidden.
5.4 Refuser tout accès si l'application ne peut pas accéder à ses informations de configuration de sécurité
Refuser tout accès si l'application ne peut pas accéder à ses informations de configuration de sécurité.
5.5 Appliquer des contrôles d'autorisation sur chaque demande, y compris celles effectuées par des scripts côté serveur
Appliquer des contrôles d'autorisation sur chaque demande, y compris celles effectuées par des scripts côté serveur.
5.6 Séparer la logique privilégiée des autres codes d'application
Séparer la logique privilégiée des autres codes d'application.
5.7 Restreindre l'accès aux fichiers ou autres ressources, y compris ceux extérieurs au contrôle direct de l'application, aux uniques utilisateurs autorisés
Restreindre l'accès aux fichiers ou autres ressources, y compris ceux extérieurs au contrôle direct de l'application, aux uniques utilisateurs autorisés.
5.8 Restreindre l'accès aux URL protégées aux utilisateurs autorisés uniquement
Restreindre l'accès aux URL protégées aux utilisateurs autorisés uniquement.
L’application Serenetics ne bénéficie d’aucune URL protégée.
5.9 Restreindre l’accès aux fonctions protégées aux seuls utilisateurs autorisés
Restreindre l’accès aux fonctions protégées aux seuls utilisateurs autorisés.
5.10 Restreindre les références d'objet directes aux seuls utilisateurs autorisés
Restreindre les références d'objet directes aux seuls utilisateurs autorisés.
Les stratégies permettent de vérifier si l’utilisateur est propriétaire ou non de l’objet concerné. Ainsi les données transmises via paramètre de l’URL ou au sein du corps de la requête sont vérifiés et confronté à l’utilisateur demandeur.
5.11 Restreindre l’accès aux services aux seuls utilisateurs autorisés
Restreindre l’accès aux services aux seuls utilisateurs autorisés.
5.12 Restreindre l'accès aux données de l'application aux seuls utilisateurs autorisés
Restreindre l'accès aux données de l'application aux seuls utilisateurs autorisés.
5.13 Restreindre l'accès aux attributs des utilisateurs et des données ainsi qu'aux informations de stratégie utilisées par les contrôles d'accès
Restreindre l'accès aux attributs des utilisateurs et des données ainsi qu'aux informations de stratégie utilisées par les contrôles d'accès.
5.14 Restreindre l'accès aux informations de configuration relatives à la sécurité aux seuls utilisateurs autorisés
Restreindre l'accès aux informations de configuration relatives à la sécurité aux seuls utilisateurs autorisés.
5.15 La mise en œuvre côté serveur et les représentations de la couche de présentation des règles de contrôle d'accès doivent correspondre
La mise en œuvre côté serveur et les représentations de la couche de présentation des règles de contrôle d'accès doivent correspondre.
5.16 Si les données d'état doivent être stockées sur le client, utiliser le cryptage et la vérification d'intégrité côté serveur pour détecter la falsification de l'état
Si les données d'état doivent être stockées sur le client, utiliser le cryptage et la vérification d'intégrité côté serveur pour détecter la falsification de l'état.
5.17 Appliquer les flux logiques des applications pour se conformer aux règles métier
Appliquer les flux logiques des applications pour se conformer aux règles métier
5.18 Limiter le nombre de transactions qu'un seul utilisateur ou appareil peut effectuer sur une période de temps donnée, suffisamment bas pour dissuader les attaques automatisées mais supérieur aux besoins réels de l'entreprise
Limiter le nombre de transactions qu'un seul utilisateur ou appareil peut effectuer sur une période de temps donnée, suffisamment bas pour dissuader les attaques automatisées mais supérieur aux besoins réels de l'entreprise.
5.19 Utiliser l'en-tête "referer" comme vérification supplémentaire uniquement, il ne doit jamais être le seul contrôle d'autorisation car il peut être usurpé
Utiliser l'en-tête "referer" comme vérification supplémentaire uniquement, il ne doit jamais être le seul contrôle d'autorisation car il peut être usurpé.
5.20 Si de longues sessions authentifiées sont autorisées, revalider périodiquement l’autorisation d’un utilisateur pour s'assurer que ses privilèges n’ont pas changé et si c’est c’est le cas, déconnecter l’utilisateur et le forcer à se ré-authentifier
Si de longues sessions authentifiées sont autorisées, revalider périodiquement l’autorisation d’un utilisateur pour s'assurer que ses privilèges n’ont pas changé et si c’est c’est le cas, déconnecter l’utilisateur et le forcer à se ré-authentifier.
Les privilèges sont toujours vérifiés.
5.21 Mettre en œuvre l'audit des comptes et appliquer la désactivation des comptes inutilisés
Mettre en œuvre l'audit des comptes et appliquer la désactivation des comptes inutilisés.
5.22 L'application doit prendre en charge la désactivation des comptes et la fin des sessions lorsque l'autorisation cesse
L'application doit prendre en charge la désactivation des comptes et la fin des sessions lorsque l'autorisation cesse.
5.23 Les comptes de service ou les comptes prenant en charge les connexions vers ou depuis des systèmes externes doivent avoir le moins de privilèges possible
Les comptes de service ou les comptes prenant en charge les connexions vers ou depuis des systèmes externes doivent avoir le moins de privilèges possible.
5.24 Créer une politique de contrôle d'accès pour documenter les règles métier, les types de données et les critères et/ou processus d'autorisation d'accès d'une application afin que l'accès puisse être correctement provisionné et contrôlé. Cela comprend l'identification des exigences d'accès aux données et aux ressources système
Créez une politique de contrôle d'accès pour documenter les règles métier, les types de données et les critères et/ou processus d'autorisation d'accès d'une application afin que l'accès puisse être correctement provisionné et contrôlé. Cela comprend l'identification des exigences d'accès aux données et aux ressources système.
5.25 Les représentations de la mise en œuvre côté serveur et de la couche de présentation des règles de contrôle d'accès doivent correspondre
Les représentations de la mise en œuvre côté serveur et de la couche de présentation des règles de contrôle d'accès doivent correspondre.
Les restrictions sont identiques sur le frontend et le backend.
PRATIQUES CRYPTOGRAPHIQUES
La gestion des pratiques cryptographiques est contrôlée par Serenetics.
6.1 Toutes les fonctions cryptographiques utilisées pour protéger les secrets de l'utilisateur de l'application doivent être implémentées sur un système de confiance
Toutes les fonctions cryptographiques utilisées pour protéger les secrets de l'utilisateur de l'application doivent être implémentées sur un système de confiance.
Tout est sur un serveur dédié, https://api.serenetics.app
6.2 Protéger les secrets contre tout accès non autorisé
Protéger les secrets contre tout accès non autorisé.
6.3 Les modules cryptographiques devraient échouer en toute sécurité
Les modules cryptographiques devraient échouer en toute sécurité.
En cas de problème lors du chiffrement ou hachage, une exception est levée et retournée au client.
6.4 Tous les nombres aléatoires, noms de fichiers aléatoires, GUID aléatoires et chaînes aléatoires doivent être générés à l'aide du générateur de nombres aléatoires approuvé par les modules cryptographiques
Tous les nombres aléatoires, noms de fichiers aléatoires, GUID aléatoires et chaînes aléatoires doivent être générés à l'aide du générateur de nombres aléatoires approuvé par les modules cryptographiques.
Aucune donnée n’est randomisée à cet effet.
6.5 Les modules cryptographiques utilisés par l'application doivent être conformes à la norme FIPS 140-2 ou à une norme équivalente
Les modules cryptographiques utilisés par l'application doivent être conformes à la norme FIPS 140-2 ou à une norme équivalente.
6.6 Établir et utiliser une politique et un processus sur la façon dont les clés cryptographiques seront gérées
Établir et utiliser une politique et un processus sur la façon dont les clés cryptographiques seront gérées.
Le mot de passe est haché conformément aux bonnes pratiques de cryptographie.
GESTION DES ERREURS ET JOURNALISATION
La gestion des erreurs et sa journalisation sont contrôlées par Serenetics.
7.1 Ne pas divulguer d'information sensible dans les réponses aux erreurs, y compris les détails du système, les identifiants de session ou les informations de compte
Ne pas divulguer d'information sensible dans les réponses aux erreurs, y compris les détails du système, les identifiants de session ou les informations de compte.
7.2 Utiliser des gestionnaires d'erreurs qui n'affichent pas d'information de débogage ou de trace de pile
Utiliser des gestionnaires d'erreurs qui n'affichent pas d'information de débogage ou de trace de pile.
7.3 Implémenter des messages d'erreur génériques et utiliser des pages d'erreur personnalisées
Implémenter des messages d'erreur génériques et utiliser des pages d'erreur personnalisées.
7.4 L'application doit gérer les erreurs d'application et ne pas s'appuyer sur la configuration du serveur
L'application doit gérer les erreurs d'application et ne pas s'appuyer sur la configuration du serveur.
7.5 Libérer correctement la mémoire allouée lorsque des conditions d'erreur se produisent
Libérer correctement la mémoire allouée lorsque des conditions d'erreur se produisent.
7.6 La logique de gestion des erreurs associée aux contrôles de sécurité doit refuser l'accès par défaut
La logique de gestion des erreurs associée aux contrôles de sécurité doit refuser l'accès par défaut.
7.7 Tous les contrôles de journalisation doivent être implémentés sur un système fiable
Tous les contrôles de journalisation doivent être implémentés sur un système fiable.
7.8 Les contrôles de journalisation doivent prendre en charge à la fois le succès et l'échec des événements de sécurité spécifiés
Les contrôles de journalisation doivent prendre en charge à la fois le succès et l'échec des événements de sécurité spécifiés.
7.9 S'assurer que les journaux contiennent des données d'événements de journal importantes
S'assurer que les journaux contiennent des données d'événements de journal importantes.
7.10 S'assurer que les entrées de journal qui incluent des données non fiables ne s'exécuteront pas en tant que code dans l'interface ou le logiciel d'affichage des journaux prévu
S'assurer que les entrées de journal qui incluent des données non fiables ne s'exécuteront pas en tant que code dans l'interface ou le logiciel d'affichage des journaux prévu.
7.11 Restreindre l’accès aux journaux aux seules personnes autorisées
Restreindre l’accès aux journaux aux seules personnes autorisées.
7.12 Utiliser une routine centrale pour toutes les opérations de journalisation
Utiliser une routine centrale pour toutes les opérations de journalisation.
7.13 Ne pas stocker d'informations sensibles dans les journaux, y compris les détails inutiles du système, les identifiants de session ou les mots de passe
Ne pas stocker d'informations sensibles dans les journaux, y compris les détails inutiles du système, les identifiants de session ou les mots de passe.
7.14 S'assurer qu'il existe un mécanisme pour effectuer l'analyse des journaux
S'assurer qu'il existe un mécanisme pour effectuer l'analyse des journaux.
7.15 Consigner tous les échecs de validation d'entrée
Consigner tous les échecs de validation d'entrée.
7.16 Enregistrer toutes les tentatives d'authentification, en particulier les échecs
Enregistrer toutes les tentatives d'authentification, en particulier les échecs.
Serenetics enregistre toutes les tentatives d'authentification.
7.17 Enregistrer tous les échecs de contrôle d’accès
Enregistrer tous les échecs de contrôle d’accès.
Serenetics enregistre tous les échecs de contrôle d’accès.
7.18 Enregistrer tous les événements de falsification apparents, y compris les modifications inattendues des données d'état
Enregistrer tous les événements de falsification apparents, y compris les modifications inattendues des données d'état.
7.19 Consigner les tentatives de connexion avec des jetons de session invalides ou expirés
Consigner les tentatives de connexion avec des jetons de session invalides ou expirés.
7.20 Consigner toutes les exceptions du système
Consigner toutes les exceptions du système.
7.21 Enregistrer toutes les fonctions administratives, y compris les modifications apportées aux paramètres de configuration de sécurité
Enregistrer toutes les fonctions administratives, y compris les modifications apportées aux paramètres de configuration de sécurité.
7.22 Consigner tous les échecs de connexion TLS backend
Consigner tous les échecs de connexion TLS backend.
7.23 Consigner les échecs du module cryptographique
Consigner les échecs du module cryptographique.
7.24 Utiliser une fonction de hachage cryptographique pour valider l'intégrité des entrées de journal
Utiliser une fonction de hachage cryptographique pour valider l'intégrité des entrées de journal.
PROTECTION DES DONNÉES
La protection des données est contrôlée et mise en place par Serenetics.
8.1 Implémenter le moindre privilège et limiter les utilisateurs aux seules fonctionnalités, données et informations système nécessaires à l'exécution de leurs tâches
