Présentation effectuée à GS Days (4 novembre 2021) par Christophe Villeneuve sur "La sécurité applicative par le design ".
Sujet : La sécurité doit commencer dès la conception d’un projet ou d’une application Web. Cette étape est nécessaire pour atténuer l’impact des cybermenaces lors de la mise en production. Cette session identifiera ce que l’on peut attendre d’une application Web sécurisée qui garantit une certaine qualité pour les données et vous protège contre les malveillances, les erreurs et la malchance, et leur impact.
4. ●
Le cas trop fréquent
●
La sécurité applicative
par le design
●
La pratique
5. @hellosct1
Réalisation une application web de base
●
Méthodologies
– Objectifs
– Analyse et préparation
– Gestion de projet → orienté métier
●
Types de réalisations d’une application web
– Application web statique
– Application web Dynamique
– Application de Type e-commerce
– Application web portail
– Application web avec gestionnaire de contenu (CMS)
11. @hellosct1
Mais : Le résultat de la réalisation
Défaut
Logique métier
Erreurs
Sécurité
Défaut
De code
Deux semaines
Piratage éthique
Plusieurs années
de développement
14. @hellosct1
Mauvais Design (1/2)
●
Impactera tôt ou tard
– Sécurité
– Maintenance
– Evolution
– Coûts du projet
https://www.koreus.com/embed/hacker-controle-voiture-distance
15. @hellosct1
Mauvais Design (2/2)
●
Cas fréquents :
– Contrôle des données en entrées
– Mauvaise usage du chiffrement
– Absence de framework
– Secrets en dur dans le code
– Manque de logs
– Système d'authentification faillible
– Hétérogénéité des environnements (OS)
– Problème entre architecture et dev
16. @hellosct1
Périmètre utilisation
●
Définir un périmètre d’utilisation
●
Si mauvais contrôle du périmètre
– Vous pouvez ouvrir un accès vers l’extérieur
●
Ex : un bluetooth ouvert
– Wifi non sécurisé
●
Nombres questions peuvent se poser !!!
17. @hellosct1
Pourquoi ? Pas de sécurité
●
Sécurité = ralenti les projets
●
Faible sensibilisation à la sécurité
●
Mauvaises pratiques de développement
●
Manque de contrôles
●
Manque d’intégration de la sécurité dans les
projets
– Préoccupation à la sécurité trop tard
18. ●
Le cas trop fréquent
●
La sécurité applicative
par le design
●
La pratique
19. @hellosct1
Sécurité applicative par le design ?
●
= Security by design
●
Modéliser
– Les risques
– Les menaces
●
Idée d’intégrer les mécanismes de protection
– Au plus tôt
– De manière plus efficiente au produit
20. @hellosct1
ISO/IEC 27034:2011
●
Norme conçu par
– L'Organisation Internationale de Normalisation (ISO)
●
But :
– Responsabiliser les organismes
●
Gestion de la sécurité de leurs applications et informations.
●
Ensemble de concepts et techniques pour garantir
– Une protection optimale de vos applications.
21. @hellosct1
Pour qui ?
●
Recommandée
– dans tous les développements d’applications
●
Parfois exigée dans les projets
– qui touchent à la sécurité de fonctionnement des
appareils
→ Impact : Ricochet à la sécurité des personnes
23. @hellosct1
Minimiser la surface d’attaque
●
La surface d’attaque représente
– Tous les points d’entrée et les points de communication
– qu’un système d’information possède avec l’extérieur.
– Concerne :
●
Logiciels (OS, librairie, accès en lecture/écriture),
●
Réseau (ports ouverts, IP actives, flux réseaux, protocoles utilisés),
●
Humaine (phishing, social engineering)
●
Physique (intrusion dans les locaux).
●
Après que tous les points de la surface d’attaque ont
été identifiés,
– Mise en place des outils de surveillance ou de protection
avancés sur ces points
24. @hellosct1
Le moindre privilège
●
Selon l’ANSSI,
– Le principe du moindre privilège stipule qu’un administrateur donné
n’a accès
●
qu’à la ou les zones d’administration dont il a le juste besoin opérationnel,
●
sans possibilité technique d’accéder à une autre zone.
– Dans les cas spécifiques des droits les plus privilégiés sur l’annuaire
lui-même,
●
seuls des administrateurs du SI d’administration peuvent en disposer.
●
Ce principe est indissociable de la sécurité by design.
– Une répartition claire des tâche, rôles et droits attribués
– Opérateur
– Administrateur système
– Administrateur local
25. @hellosct1
La défense en profondeur
●
Terme emprunté à une technique militaire destinée à retarder l’ennemi,
– La défense en profondeur consiste à exploiter plusieurs techniques de sécurité
●
Réduire le risque lorsqu’un composant est compromis ou défaillant.
●
Pour mettre en place cette défense en profondeur,
– Les étapes recommandées sont les suivantes :
●
Détermination des objectifs de sécurité pour construire la stratégie de défense en
profondeur,
●
Élaboration de l’organisation et de l’architecture générale du système pour définir les
points de contrôle et d’évaluation,
●
Élaboration de la politique de défense,
●
Qualification du système au regard des critères de défense en profondeur,
●
Évaluation de la défense permanente et périodique à partir des méthodes d’attaques et du
retour d’expérience (contrôle et audit).
●
La démarche de la sécurité by design doit être étendue
– Au-delà de la phase de conception,
– Elle doit être prise en compte tout au long du cycle de vie du produit.
26. @hellosct1
Approche par les risques
●
4 axes :
– Stratégie d’entreprise
– Pilotage des processus métier
●
Approche fonctionnelle et orientée métier
– Urbanisation du SI
●
Fonctionnel orienté applications & données
– Architecture technique
●
avec le socle technique de l’infrastructure
●
Si j’ai tel scénario → le comportement attendu
– voir si le code correspond à ce qu’on attend
32. @hellosct1
Brainstorming de la sécurité (1/2)
●
Nouveau projet
et / ou
●
Evolution du projet
→ Une nouvelle fonctionnalité
Chaque participant
a sa vision
de la sécurité
34. @hellosct1
Check list : Se poser les bonnes questions ?
●
Comment développer de nouvelles applications
●
Ajouter des nouvelles fonctionnalités à des
applications en production
→ Sans introduire de nouvelles vulnérabilités
→ Compromettre une infrastructure en mode Run
35. @hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
Double authentification
●
Logs
●
Applications web
●
Caractéristiques sécurité
●
Base de données
●
Problèmes courants
●
Différents niveaux
36. @hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
Double authentification
●
Logs
●
Applications web
●
Caractéristiques sécurité
●
Base de données
●
Problèmes courants
●
Où se trouve l’hébergement
●
Définir une tranche IP
– Contrôle IP ?
●
L’archivage des données
●
Interface d’administration
●
TLS
●
Port ouvert
●
Déploiement
●
PRA
●
...
37. @hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
Double authentification
●
Logs
●
Applications web
●
Caractéristiques sécurité
●
Base de données
●
Problèmes courants
●
Configuration du dépôt
– de code est correcte
●
Applications construites en
interne
– doivent être hébergées dans des
organisations de confiance
●
Sécurisez votre dépôt
●
Taggué vos versions
– Important pour les commits
●
Dépendance avec les langages
●
Utilisez une liste blanche
d’outils (VM, IDE...)
●
...
38. @hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
Double authentification
●
Logs
●
Applications web
●
Caractéristiques sécurité
●
Base de données
●
Problèmes courants
●
Captcha
●
Mise en place d’une
2FA
– Push / Pull des
données
●
Pré-Validation
39. @hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
Double authentification
●
Logs
●
Applications web
●
Caractéristiques sécurité
●
Base de données
●
Problèmes courants
●
Logs détaillés dans un
format dédié
●
Historisation
– des connexions
●
Logs métiers
– avec du code
spécifique
●
Logs sur les échecs
– Au niveau WARN
●
...
40. @hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
Double authentification
●
Logs
●
Applications web
●
Caractéristiques sécurité
●
Base de données
●
Problèmes courants
●
Doit avec une politique de
sécurité de contenu (CSP)
●
Définir ou n’autoriser que des
sources spécifiques
– Object, image
●
L’utilisation de librairie JS taggé
avec une version précise
●
Temps de réponse à prévoir pour
le hors HTML
●
L’utilisation de Tokens (jetons)
unique + chiffré
●
La sécurité des cookies
●
Valider la sécurité à chaque étape
●
…
41. @hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
Double authentification
●
Logs
●
Applications web
●
Caractéristiques sécurité
●
Base de données
●
Problèmes courants
●
L’authentification par palier
– Utilisateurs / Admin / …
●
Actu ou B2B
●
Définir les rôles & droits
●
Stockage de clés de session
– Côté serveur (ex BDD)
●
Cookies de session
●
Formulaire de recherche
avancé dynamique
●
Des dépendances à des
extensions / plugins
42. @hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
Double authentification
●
Logs
●
Applications web
●
Caractéristiques sécurité
●
Base de données
●
Problèmes courants
●
Toutes les requêtes
SQL
– Paramétrées
– Concaténées
●
Des comptes (accès)
– spécifiques au projet
●
Un rôle
administrateur
– Dédié à prévoir
43. @hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
Double authentification
●
Logs
●
Applications web
●
Caractéristiques sécurité
●
Base de données
●
Problèmes courants
●
Sécurisé les données
– Utilisateurs de l’application
●
Appliquez des limites aux
entrées de l’utilisateur
●
Taille spécifique dans les
POST
●
Gestions des clés utilisées
– Session / Permission / …
●
Mécanismes de rotation des
clés ou données sensibles
●
Définir les échecs possibles
(ex Code Postal)
46. @hellosct1
Maintenance en production
●
Régulièrement
– Surveillance des logs
– Fonctions et/ou API obsolètes
– Firewall applicatif
– Scans réguliers
– Tests d’intrusions
●
Quand le problème de sécurité est identifié
– Actions :
●
Elaborer un test
●
Comprendre la cause du problème
●
Conséquence de cette faille
– Réactivé à corriger une faille / une vulnérabilité
49. @hellosct1
En résumé
●
Impact tous les métiers
●
La sécurité d’une application
– ajoute une couche supplémentaire de sécurité
→ A l’ensemble du SI
●
Impact les performances globales
– Une application
– Une infrastructure
●
La sécurité tardive
→ impact sera important
52. @hellosct1
C’est pourquoi !!!
●
La sécurité applicative par le design
– Démarche qui peut être
●
enrichie, adaptée et appliquée
●
selon le contexte de chaque métier.
– Participe à la mise en place
●
d’une bonne hygiène informatique
●
Permet une maîtrise optimale
– du niveau de sécurité de l’infrastructure.
– Dissuade les pirates
●
En limitant la surface d’attaque du SI
●
De l’application sur une petite échelle.
53. @hellosct1
On continue dans le DevSecOps / SecDevOps...
meetup lizard
https://www.meetup.com/fr-FR/lizard_secu/