- 1. Introduction
- 2. Non statué
- 3. Contraintes
- 4. Exigences
- 4.1. Exigences d’intégrité
- 4.2. Exigences de confidentialité
- 4.3. Exigences d’identification
- 4.4. Exigences d’authentification
- 4.5. Exigences de fédération d’identité
- 4.6. Exigences de SSO et SLO
- 4.7. Exigences de non répudiation
- 4.8. Exigences d’anonymat et de respect de la vie privée
- 4.9. Exigences sur les habilitations
- 4.10. Exigences de traçabilité et d’auditabilité
- 5. Mesures de sécurité
- 6. RACI
- 7. Auto-contrôles
Dernière modification : 2024-08-24
Date dernière revue globale : <Faire régulièrement des revues complètes de la vue (au moins une fois par an tant que le projet est actif) et mentionner la date ici>
Statut du document : <Donner ici le statut de la vue, par exemple 'DRAFT', 'FINALISÉ',…>
Ceci est la vue sécurité. Elle décrit l’ensemble des dispositifs mis en œuvre pour empêcher l’utilisation non-autorisée, le mauvais usage, la modification illégitime ou le détournement des modules applicatifs.
Les autres vues du dossier sont accessibles d’ici.
Le glossaire du projet est disponible ici. Nous ne redéfinirons pas ici les termes fonctionnels ou techniques utilisés.
|
Tip
|
La disponibilité est traitée dans la vue infrastructure. |
|
Tip
|
Mentionner ici les documents d’architecture de référence (mutualisés). Ce document ne doit en aucun cas reprendre leur contenu sous peine de devenir rapidement obsolète et non maintenable. |
| N° | Version | Titre/URL du document | Détail |
|---|---|---|---|
1 |
1.0 |
Dispositifs_securite.pdf |
Catalogue de dispositifs de sécurité habilités |
2 |
latest |
Normes sécurité société |
| ID | Détail | Statut | Porteur du sujet | Échéance |
|---|---|---|---|---|
ES1 |
Il conviendra de valider que les dispositifs anti-CSRF mis en place résolvent également les failles liées au couplage TLS + compression (type CRIME ou BREACH). |
EN_COURS |
Équipe sécurité |
AVANT 2040 |
|
Tip
|
Lister ici les contraintes relatives à la sécurité, ceci inclut par exemple mais pas seulement :
|
Exemple 1 : la politique de mot de passe devra se conformer à la norme xyz
Exemple 2 : il est formellement interdit à un composant de la zone internet d’accéder à la zone intranet
Exemple 3 : en application du RGPD, les données utilisateur devront être chiffrées
|
Tip
|
Présenter ici les exigences, pas les dispositifs y répondant. Ceux-ci seront détaillés au chapitre 3. Pour les projets particulièrement sensibles, prévoir un dossier d’analyse de risque. Pour cela, utiliser par exemple la méthode EBIOS Risk Manager (Expression des Besoins et Identification des Objectifs de Sécurité). |
|
Tip
|
L’intégrité concerne la durabilité, la justesse et le niveau de confiance dans les données de l’application. Gérer l’intégrité des données consiste à vérifier qu’elle ne peuvent être altérées ou supprimées (involontairement, suite à un crash disque par exemple) ou volontairement, par exemple dans le cadre d’une attaque de type "man in the middle" ou par une personne s’étant octroyé des droits indus. Attention à ne pas multiplier les classes de données. Il est possible de ne définir qu’une seule classe de donnée pour l’ensemble de l’application (cas courant). |
Classe de données |
Niveau « Non intègre » (La donnée peut ne pas être totalement intègre) |
Niveau « Détectable » (La donnée peut ne pas être intègre si l’altération est identifiée dans un délai raisonnable) |
Niveau « Maîtrisé » (La donnée peut ne pas être intègre, si l’altération est identifiée et l’intégrité du bien essentiel retrouvée) |
Niveau « Intègre » (La donnée doit toujours être rigoureusement intègre) |
Données de la base métier |
X |
|||
Données archivées |
X |
|||
Données calculées stats entreprises |
X |
|||
Silo NoSQL des données Big Data avant consolidation |
X |
|||
Sources de l’application |
X |
|||
Avis d‘imposition en PDF |
X |
|
Tip
|
La confidentialité est le fait de s’assurer que l’information n’est accessible qu’à ceux dont l’accès est autorisé (norme ISO 27018). Attention à ne pas multiplier les classes de données. Il est possible de ne définir qu’une unique classe de donnée pour l’ensemble de l’application (cas courant). |
Classe de données |
Niveau « Public » (Tout le monde peut accéder à la donnée) |
Niveau Limité » (La donnée n’est accessible qu’aux personnes habilitées) |
Niveau « Réservé » (La donnée n’est accessible qu’au personnel interne habilité) |
Niveau « Privé » (La donnée n’est visible que par l’intéressé(e)) |
Contenu éditorial |
X |
|||
Données de profil de l’utilisateur |
X |
|||
Historique du compte |
X |
|||
Logs techniques des activités |
X |
|||
Données RH de type "aides sociales aux employés" |
X |
|
Tip
|
L’identification est l’ensemble des dispositifs permettant de différentier un utilisateur d’un autre (mais sans vérifier qu’il est bien celui qu’il prétend être). |
Exemple 1 : Un utilisateur ne peut avoir qu’un unique identifiant et un identifiant ne peut être partagé par plusieurs utilisateurs. L’adresse e-mail personnelle est donc un bon identifiant.
Exemple 2 : L’identité d’un internaute fera l’objet d’un test d’existence avant tout appel de service.
Exemple 3 : Un ID est non supprimable, non modifiable et non réutilisable.
|
Tip
|
L’authentification permet de vérifier la cohérence entre l’identité d’un utilisateur et une personne physique se connectant. A noter que les dispositifs techniques (comme les batchs) peuvent également faire l’objet d’identification et d’authentification (batch qui utilise un compte de service pour appeler une API par exemple). L’authentification peut être à un ou plusieurs facteurs (dans ce dernier cas, on parle d’authentification forte). Ces facteurs peuvent être :
Penser à décrire le système d’authentification une fois inscrit mais également lors de l’inscription (authentification initiale). Une éventuelle délégation d’authentification s’appuie sur une technologie de fédération d’identité pour authentifier l’utilisateur. Il est bien sûr possible d’ajouter au besoin dans le tableau ci-dessous des facteurs d’authentification spécifiques à votre organisation. |
Les facteurs d’authentification requis en fonction des situations sont (on peut exiger plusieurs occurrences du même facteur, utiliser autant de croix) :
Cas d’authentification |
Mot de passe respectant la politique de mot de passe |
Clé publique ssh connue |
OTP par Token |
Biométrie |
Connaissance de données métier |
E-mail avec hyperlien de vérification |
Utilisateur déjà inscrit |
X |
|||||
Création d’un compte |
XX |
X |
||||
Modification du mot de passe |
X |
X |
||||
Accès aux logs |
X |
|||||
Ajout d’un bénéficiaire de virement |
X |
X |
||||
Application mobile Y |
X |
|
Tip
|
La fédération d’identité est l’utilisation d’une même identité gérée par un identity provider (IdP) depuis plusieurs entités différentes. Par exemple, France Connect très utilisé par les administrations et basé sur OpenId Connect permet de réutiliser le compte d’une administration pour se loguer sur le compte d’une autre (DGFiP et CNAM par exemple). Voir aussi les « Connect with [Google|Twitter|…] » en technologie OpenId Connect. Contrairement au SSO, la fédération d’identité n’assure pas un login automatique à une application comme le SSO mais permet simplement de réutiliser les mêmes credentials (login/mot de passe). |
Exemple : L’identification et l’authentification seront externalisés au fournisseur d’identité Auth0 pour simplifier la gestion de la sécurité et réduire les coûts de développement et d’exploitation.
|
Tip
|
Décrire les besoin en terme de Single Sign On et Single Log Out. Nous entendons ici SSO dans son sens le plus complet : une authentification automatique à une application d’un utilisateur déjà authentifié depuis une autre application du même domaine de confiance. Attention, la mise en place de SSO peut être complexe, surtout si l’infrastructure (ID provider…) n’existe pas encore. Elle nécessite souvent une adaptation des applications. Le SSO est souvent demandé par les métiers mais cette exigence doit être justifiée. Une application périphérique ou un outil rarement utilisé n’a en général pas besoin de SSO (une simple authentification centralisée au sein d’un annuaire peut suffire). Attention également à évaluer l’impact qu’aurait une authentification faible (mauvais mot de passe par exemple) sur la sécurité de l’ensemble du SI. |
Exemple 1 : aucun SSO n’est exigé puisque toutes les IHM de l’application sont exposées au sein d’un portail JSR352 qui gère déjà l’authentification.
Exemple 2 : aucun besoin de SSO ou SLO n’est identifié
Exemple 3 : cette application Web métier devra fournir une authentification unique mutualisée avec celle des autres applications de l’intranet : une fois authentifié sur l’une des applications, l’agent ne doit pas avoir à se reconnecter (jusqu’à expiration de sa session). De même, une déconnexion depuis l’une des applications doit assurer la déconnexion de toutes les applications de l’intranet.
|
Tip
|
Lister ici les actions métiers possédant une exigence de non-répudiation, c’est à dire un dispositif permettant de rendre impossible la remise en cause d’un contrat en prouvant l’identité des deux parties et l’intégrité du document par signature numérique comme décrit dans le texte n°2000-230 du 13 mars 2000 du code civil. |
| Donnée signée | Origine du certificat client | Origine du certificat serveur |
|---|---|---|
Déclaration d’impôt sur le revenu (données X, Y et Z) |
PKI de l’administration fiscale |
Verisign |
|
Tip
|
Lister les contraintes d’anonymat et de vie privée légale (exigée par le RGPD). Voir https://www.cnil.fr/fr/rgpd-par-ou-commencer. |
Exemple 1 : Aucune consolidation de donnée ne pourra être faite entre les données du domaine PERSONNE et du domaine SANTE.
Exemple 2 : Par soucis de confidentialité en cas d’intrusion informatique, certaines données des personnes seront expurgées avant réplication vers la zone publique : le taux de cholestérol et le poids.
Exemple 3 : aucune donnée raciale, politique, syndicales, religieuse ou d’orientation sexuelle ne pourra être stockée sous quelque forme que ce soit dans le SI.
Exemple 4 : Les données OpenData issues du domaine « logement » ne contiendront que des données consolidées de niveau commune, pas plus précise.
Exemple 5 : En application de la directive européenne « paquet telecom », un bandeau devra informer l’usager de la présence de cookies.
Exemple 6 : En application du RGPD, un consentement explicite des utilisateurs dans la conservation de leurs données personnelles de santé sera proposé.
|
Tip
|
Une habilitation (ou autorisation) permet de donner l’accès à une fonction applicative (ou « privilège » ou « permission ») à un utilisateur ou un groupe d’utilisateur. Exemples de fonctions : 'faire un virement inter-bancaire', 'voir l’historique de son compte', 'supprimer un utilisateur' Attention à ne pas multiplier le nombre de fonctions et de rôles pour éviter une explosion combinatoire et des coûts de gestion associés. Pour simplifier la gestion des habilitations par factorisation, on peut :
Exemple de modèle classique de gestion des habilitations : 
Penser à spécifier les éventuels pseudo-utilisateurs et leurs rôles comme :
Préciser si l’application doit utiliser de la délégation d’autorisation (type OAuth2) et si oui, l’application est-elle fournisseur ou consommateur d’autorisations ? Quelles sont les autorisations concernées ? |
Exemple 1 : les personnes non connectées auront accès à tous les privilèges en lecture seule
Exemple 2 : l’application s’appuiera sur une gestion des autorisations matricielle de type [rôles] → [groupes ou utilisateurs] comme décrit plus bas. Le détail des autorisations sera donnée dans les SFD.
| Groupe ou utilisateur | Rôle suppression |
Rôle administration |
_Rôle _consultation données de base |
|---|---|---|---|
Groupe |
X |
||
Groupe |
|||
Groupe |
X |
X |
X |
Utilisateur |
X |
X |
|
Tip
|
Lister ici les besoins en traces permettant de détecter par exemple :
Les traces sont des données nominatives et complètes pour permettre l’audit. Elles sont donc elles-mêmes sensibles et nécessitent souvent un bon niveau de confidentialité. Différentier :
Pour les données les plus sensibles, il est possible de prévoir une traçabilité à deux niveaux (tracer la consultation des traces) pour éviter une traçabilité hiérarchique abusive. La traçabilité des données des référentiels (base des personnes typiquement) nécessite une historisation complète, ce qui est de toute façon une bonne pratique d’urbanisation (voir par exemple Longépé « Le projet d’Urbanisation du SI », règles applicatives 1, 2 et 3). Pour cela, prévoir un MCD permettant d’ajouter un enregistrement à chaque changement de la donnée avec une date de modification et une date d’effet. |
Exemple 1 : pour le module X, toute action métier (en mise à jour comme en consultation) devra faire l’objet d’une trace métier contenant a minima l’agent, la date et en cas de modification l’ancienne et la nouvelle valeur.
Exemple 2 : Toute intrusion dans le SI devra être détectée (dans la mesure du possible).
Exemple 3 : nous devons pouvoir reconstituer l’historique du dossier de tout patient à n’importe quelle date.
| Donnée | Objectif | Durée de rétention |
|---|---|---|
Log complet (IP, heure GMT, détail) des commandes passées sur le site |
Prouver que la commande a bien été passée |
1 an |
Date et contenu du mail de confirmation |
Prouver que le mail de confirmation a bien été envoyé |
2 ans |
Contrat d’assurance signé et numérisé en PDF |
Prouver que le contrat a bien été signé |
5 ans |
Avis d’imposition primitif avec signature numérique |
Conserver le montant et de l’impôt. |
5 ans |
Dispositifs répondant aux exigences d’intégrité :
| Classe de données | Niveau exigé | Mesures |
|---|---|---|
Données de la base métier |
Intègre |
|
Données archivées |
Détecté |
Génération de checksums SHA-256 des backups |
Données calculées D1 |
Maîtrisé |
Stockage d’un checksum SHA1, relance du calcul automatiquement par batch dans les 24H. |
Silo NoSQL des données Big Data avant consolidation |
Non intègre |
Pas de mesure particulière, pas de backup |
Sources |
Intègre |
Utilisation du SCM Git |
Avis d’imposition PDF |
Intègre |
Signature numérique du montant net + date + nom au format PKCS#7 (RSA, SHA256) avec horodatage. La signature résultante sera intégrée a posteriori au format hexadécimal en pied de page du PDF. |
Dispositifs répondant aux exigences de confidentialité :
| Classe de données | Niveau exigé | Mesures |
|---|---|---|
Contenu éditorial |
Public |
Échanges en HTTPS, pas d’authentification |
Profil du compte du site Web |
Limité |
L’accès à ce contenu nécessite une authentification réussie par login/mot de passe |
Historique du compte |
Réservé |
L’accès à ce contenu est réservé aux exploitants habilités, uniquement via des requêtes PL/SQL de la base de données |
Logs des activités de l’internaute |
Réservé |
L’accès aux fichiers de log est réservé aux exploitants habilités (accès SSH à la machine M et mot de passe Unix) |
Données RH aides sociales aux employés |
Privé |
Ces données sont chiffrées en AES 256 sous forme d’un BLOB en base, remontées au client Web via le service REST Y puis déchiffrées au sein du navigateur dans l’application Angular (librairie forge.js) via un mot de passe complémentaire de l’utilisateur (non stocké coté serveur). |
|
Tip
|
Penser aussi à la confidentialité des données dérivées :
|
Dispositifs répondant aux exigences d’identification :
Exemple 1 : L’Id des usagers de l’application sera l’attribut uid des DN cn=XXX,ou=service1,dc=entreprise,dc=com dans l’annuaire LDAP central. Un filtre sera également appliqué sur l’appartenance au groupe ou=monapplication,dc=entreprise,dc=com.
Exemple 2 : Pour assurer la non réutilisation des ID des comptes supprimés, une table d’historique sera ajoutée dans l’application et requêtée avant toute création de nouveau compte.
Dispositifs répondant aux exigences d’authentification :
|
Tip
|
Pour les authentifications par mot de passe, décrire le mode de stockage et de vérification. Penser également à décrire les solutions de changement de mot de passe. |
Exemple 1 : L’authentification des internautes inscrits se fera par login/mot de passe (respectant la politique de mot de passe P)
Exemple 2 : L’authentification des internautes à l’inscription se fera par la saisie du code internaute figurant sur les factures + la valeur de la dernière facture puis par l’activation du compte via un lien figurant dans un e-mail de vérification.
Exemple 3 : lors de la création d’un nouveau bénéficiaire de virement dans l’espace internet, l’utilisateur devra fournir un mot de passe unique issu de son token OTP en plus d’être authentifié.
Exemple 4 : Les mots de passe ne seront en aucun cas conservés mais stockés sous la forme de digest bcrypt.
Dispositifs répondant aux exigences de fédération d’identité :
|
Tip
|
Les solutions les plus courantes sont actuellement : OpenId Connect (OIDC), SAML ou Oauth 2.0 (pseudo-authentification seulement pour cette dernière). Pour les applications Web, préciser les contraintes navigateur (activation des cookies en particulier). |
Exemple : L’IHM grand public permettra une identification et authentification France Connect (basé sur OIDC) de sorte que les utilisateurs puissent utiliser leur compte DGFiP ou CNAM pour s’identifier et s’authentifier. La cinématique d’authentification sera la suivante : <faire un schéma>
Dispositifs répondant aux exigences de SSO et SLO :
|
Tip
|
Détailler la technologie choisie et son intégration. Quelques solutions courantes : CAS, OpenAM, LemonLDAP::NG. Pour les applications Web, préciser les contraintes navigateur (activation des cookies en particulier). |
Exemple 1 : L’IHM X intégrera un client CAS spring-security pour le SSO. Le serveur CAS utilisé sera YYY. Son royaume d’authentification (realm) sera l’annuaire AD Y.
Exemple 2 : Comme toutes les applications du portail métier, l’IHM X devra gérer les callbacks de déconnexion provenant du serveur CAS suite à une demande de SLO.
|
Tip
|
Les comptes de service sont utilisés pour l’authentification à un composant technique depuis un batch ou une API. |
| Compte | Ressource requérant authentification | mode de stockage des credentials |
|---|---|---|
Comptes JDBC (un compte par base de données) |
Instances PG et SqlServer. |
Stockage en clair dans la configuration des datasources. Valorisé à partir des pilars Salt des API. |
Dispositifs répondant aux exigences de non répudiation :
Exemple : La déclaration d’impôt sera signée par le certificat client de l’usager (certificat X509, RSA, SHA-256) qui lui a été fourni par le composant X.
|
Tip
|
Les solutions d’horodatage cryptographiques ne répondent pas à un besoin propre mais sont souvent requis pour répondre à des besoins de non répudiation (spécialement via des jetons d’horodatage utilisés conjointement avec une signature électronique afin de prévenir d’antidatage ou le postdatage). |
Exemple : Les signatures électroniques seront accompagnées d’un jeton d’horodatage qualifié eIDAS délivrés par le prestataire de service de confiance XYZ.
Dispositifs répondant aux exigences d’anonymat et de respect de la vie privée :
Exemple 1 : un audit interne sera mené une fois par an sur le contenu des données en base et les extractions à destination des partenaires.
Exemple 2 : les données à destination de la zone publique seront exportées partiellement via un COPY (SELECT …) TO <fichier>. Les colonnes sensibles seront ainsi exclues de la réplication.
Exemple 3 : le bandeau d’acceptation des cookies sera mis en ouvre sur toutes les pages de l’application Angular via le module angular-cookie-law.
Dispositifs répondant aux exigences sur les habilitations :
Exemple 1 : la gestion des autorisations sera gérée applicativement et stockée dans la base applicative PostgreSQL. Ces tables seront décrites dans le dossier de spécification.
Exemple 2 : L’obtention du carnet d’adresse Facebook sera en OAuth2. On utilisera l’API Java Google Oauth2.
Dispositifs répondant aux exigences de traçabilité et d’auditabilité :
Exemple 1 : à la fin de chaque action métier, l’application ReactJS appellera dans une action asynchrone un service REST de trace métier. Ce service stockera les traces dans une base Elastic Search pour consultation en Kibana.
Exemple 2 : l’outil d’IDS hybride (réseau + host) OSSEC sera installé sur l’ensemble des machines utilisées par l’application.
Exemple 3 : Les tables X, Y, .. seront historisées suivant le principe suivant : … <diagramme de classe>
Exemple 4 : tous les documents servant de preuve seront archivés dans la GED.
Exemple 5 : Les logs contenant le tag [PREUVE] et issu de l’ensemble des composants seront centralisés via le système de centralisation de log Elastic Search puis insérés avec traitement Logstash de façon journalière vers l’index Elastic preuves.
Ces dispositifs techniques ou organisationnels permettent de lutter contre les cybermenaces, comme les malwares, le phishing, les attaques DOS/DDOS, l’exploitation de vulnérabilités (connues ou zero-day), l’ingénierie sociale, les escroqueries en ligne, les fuites de données sensibles, etc. La plupart des solutions sont mises en œuvre au niveau du Système d’Information (SI). Il s’agit donc probablement ici de pointer vers les documents de référence et de détailler les éventuelles solutions spécifiques à votre projet ou produit.
Incluent :
-
Les formations et sensibilisations des utilisateurs.
-
Les formations et sensibilisations des acteurs informatiques.
-
La mise en place d’un système de prévention d’intrusion (IPS) qui bloque les acteurs jugés malicieux.
-
La mise en place et le respect des procédures, comme les revues régulières d’habilitations.
-
Le durcissement des règles de sécurité comme imposer l’authentification à facteurs multiples obligatoires, le renouvellement obligatoire des mots de passe ou l’utilisation de coffres-fort numériques (personnels ou partagés) pour stocker les secrets.
-
La réalisation régulière d’audits (tests de pénétration et/ou audit de code) si possible par des experts externes.
-
Les outils de prévention de la perte de données (DLP) qui analysent notamment les flux réseau ou les emails à la recherche de fuites de données sensibles ou de propriété intellectuelle.
-
Le blocage de certains systèmes vecteurs d’attaques comme les clés USB.
-
Les systèmes de mises à jour automatiques des patches de sécurité sur les systèmes d’exploitation.
Exemple 1 : Sensibilisation des utilisateurs via ces recommendations de l’ANSSI.
Exemple 2 : Sensibilisation au risque auprès des acteurs informatiques via les guides essentiels de l’ANSSI.
Exemple 3 : Mise en place de l’IPS OpenSource CrowdSec basé sur le partage d’information communautaire (Crowdsourcing).
Incluent :
-
Les antivirus (dont les dernières générations incluent de l’IA et vont au-delà de la recherche de signatures).
-
Les WAF (Web Application Firewall) qui détectent et bloquent les tentatives d’attaques en temps réel.
-
Les outils de SIEM (Security Information and Event Management) qui analysent les logs issus de sources variées.
-
Les outils d’IDS (Intrusion Detection System), assurant souvent également la fonction d’IPS et analysant les flux réseau à la recherche de tentatives d’accès malicieux (comme des tentatives d’exploitation de CVE).
-
Les outils SAST (Static Application Security Testing) et DAST (Dynamic Application Security Testing) analysant respectivement le code source de l’organisation et le comportement à l’exécution, à la recherche de vulnérabilités connues.
-
Les outils SCA (Software Composition Analysis) analysant les dépendances (essentiellement Open Source) des projets et remontant la liste des CVE (vulnérabilités connues) dès que possible en vue de les mettre à jour.
Exemple 1 : Mise en place au sein des pipelines de CI/CD de l’outil SCA OWASP Dependency-Check permettant de détecter les librairies Open Source contenant des vulnérabilités (CVE). Toute présence de CVE doit être bloquante.
Incluent :
-
Les solutions anti-malware qui suppriment les logiciels malveillants.
-
Les outils de restauration de sauvegardes (la connaissance du MTTR, défini dans la vue infrastructure, est cruciale pour la planification de la restauration).
-
Les outils et procédures permettant l’isolation de composants ou de zones compromises au sein du SI.
-
Les outils de gestion de parc logiciel qui bloquent les logiciels non autorisés.
-
Les outils et méthodologies d’analyse forensique permettant d’analyser les logs pour comprendre les chemins d’une attaque et construire un post-mortem.
-
Les procédures et outils de réponse à une attaque.
Exemple 1 : Préparation de procédures et d’un plan de secours en cas d’incident de sécurité suivant le standard NIST SP 800-61.
Ces solutions récentes sont essentiellement basées sur du Machine Learning et l’analyse de données en masse (Big Data). Elles incluent :
-
Les solutions de type User and Entity Behavior Analytics (UEBA) qui permettent de détecter les comportements anormaux de certains utilisateurs.
-
Les outils de simulations d’attaques complexes ;
-
Les outils et référentiels de renseignement sur les menaces (Threat Intelligence).
Exemple 1 : Analyse et alerting des comportements suspects avec AWS GuardDuty sur une application cloud déployée sur AWS.
Exemple 2 : Utilisation de CrowdSec Threat Intelligence pour découvrir les tendances des menaces basées sur des données réelles et consolidées.
|
Note
|
Ce RACI permet de définir clairement les rôles de chacun concernant les actes liés à la sécurité.
|
| Équipe Systèmes & Cloud | Équipe Sécurité SI | Équipe Réseau | |
|---|---|---|---|
Création des accounts AWS |
R & A |
C & I |
A |
Création des SCP AWS |
R & A |
C & I |
A |
|
Tip
|
La gestion des vulnérabilités dépasse largement le cadre de ce document mais il est bon de s’auto-contrôler pour s’assurer que les failles les plus courantes sont bien prises en compte et comment. Cette liste est en partie basée sur le TOP 10 OWASP. Bien entendu, il existe de nombreux autres points de contrôle dépendants du contexte de l’application |
Vulnérabilité |
Prise en compte ? |
Mesures techniques entreprises |
Accès à des ports privés |
X |
Configuration du pare-feu iptables sur la machine exposée à Internet. Seul les ports 80 et 443 sont ouverts. Le pare-feu sera configuré en mode stateful (avec extension conntrack) |
Attaque de mot de passe par force brute |
X |
Utilisation de fail2ban, mise en prison de 1h au bout de 3 tentatives de connexion ssh. |
Visibilité des URLs directes |
X |
Centralisation de tous les accès depuis Internet via un reverse proxy Apache + mod_proxy. Réécriture d’URLs pour masquer les URL internes. |
Contournement du contrôle d’accès |
X |
Utilisation du SSO CAS, voir chapitre 3 |
Injection SQL |
X |
Utilisation de PreparedStatement uniquement, audit des requêtes SQL. |
Injection NoSQL |
X |
Désactivation du suport JS par MongoDB |
Injection OS |
X |
Vérification qu’il n’y a aucun appel de commandes systèmes dans le code (type Runtime.exec() ) |
Violation de gestion d’authentification et de session |
X |
Traité avec le dispositif anti-CSRF, voir plus bas. On logue l’IP à fin d’audit. |
XSS |
X |
|
ReDOS |
X |
Vérification que les expressions régulières utilisées par les dispositifs anti-XSS ne sont pas éligibles à ce type d’attaque, voir https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS |
Référence directe à un objet |
X |
Vérification à chaque requête que les arguments passés correspondent bien à la personne identifiée. Par exemple, toute requête contient son ID et on vérifie par une requête que le dossier qu’elle tente de consulter lui appartient bien avant de poursuivre la requête initiale. |
Planification des mises à jour de sécurité |
X |
|
Exposition de données sensibles |
X |
|
CSRF |
X |
Utilisation du dispositif anti-CSRF d’AngularJS (https://docs.angularjs.org/api/ng/service/$http ) |
Manque de contrôle d’accès au niveau fonctionnel |
X |
|
Log injection |
X |
|
Attaques HTTPS + compression CRIME/BREACH |
X |
|
Upload de fichiers malicieux |
X |
Validation des pièces jointes par l’anti-virus ClamAV |
|
Tip
|
Cette section aide à vérifier la prise en compte des exigences du RGPD. A noter que le RGPD ne concerne que les personnes physiques, pas les personnes morales. Cette liste n’est qu’un exemple partiel, faire valider votre projet par votre service sécurité et juridique. |
Exigence RGPD |
Prise en compte ? |
Mesures techniques entreprises |
Registre du traitement de données personnelles |
X |
Liste des traitements et données personnelles dans le document XYZ |
Pas de données personnelles inutiles |
X |
Vérifié, la rétention de numéro de CB a été supprimée car inutile. |
Droits des personnes (information, accès, rectification, opposition, effacement, portabilité et limitation du traitement.) |
X |
Oui, traitement manuel sur demande depuis le formulaire situé à http://xyz, traitement en 1 mois max |
Sécurisation des données |
X |
Oui, voir les mesures listées dans ce document notamment sur la confidentialité, audibilité et intégrité. |