La sécurité applicative par le design

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.

Transcript

1. La sécurité applicative par le design Christophe Villeneuve @hellosct1 @hellosct1@mamot.fr le 4 novembre 2021 de la théorie à la pratique
2. @hellosct1 Atos open source - afup – lemug.fr – mariadb – drupal – mozilla - firefox – lemugfr - sumo – webextensions – VR – AR – XR - Cause commune 93.1 FM - TechSpeaker - Lizard - eyrolles – editions eni – programmez – linux pratique – webriver – elephpant - CommonVoice – Sécurité - Cybersécurité Christophe Villeneuve • Consultant Open Source • Dresseur animaux
3. @hellosct1 Aujourd’hui • Le ‘cas’ trop fréquent • La sécurité applicative par le design • La pratique
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)
6. @hellosct1 Application web • Plusieurs technologies associées Ajouter un nouvel outil ou une nouvelle envie
7. @hellosct1 CRM Intranet Website Tracker Service Auth. Web Service Serveur Web Firewall Base de données Access Control Architecture d'une application Web
8. @hellosct1 Architecture d'une application Web (2/2)
9. @hellosct1 Evolution : déploiement continue • Automatisation Développement Serveur validation Serveur intégration Outils SCA Tâches répétitives - Analyse de code - Contrôle du code - Déclencheur Build Serveur Préprod Serveur production Tests de sécurité automatisé Report & Notification
10. @hellosct1 Tout est beau.. Tout est merveilleux
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
12. @hellosct1 Alors...
13. @hellosct1 Allo… Docteur ? • De nombreux problèmes → présent • Dérive du projet • ... Mauvais DESIGN
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
22. @hellosct1 3 grands principes • Minimiser la surface d’attaque • Le moindre privilège • La défense en profondeur
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
27. @hellosct1 Documentations (1/2) • Aucune norme ou concept – par des standards • Référentiels et bonnes pratiques – Viega & McGraw – Owasp – Nist – NCSC – Cliff Berg’
28. @hellosct1 Documentations (2/2) • OWASP Session Management Cheat Sheet – https://www.owasp.org/index.php/Session_Management_Cheat_Sheet • Mozilla Observatory – https://observatory.mozilla.org/ • Les principes de Security by design (Owasp) – https://wiki.owasp.org/index.php/Security_by_Design_Principles • Entrée TOP 10 – 2021 OWASP – A04:2021 – Insecure Design • https://owasp.org/Top10/A04_2021-Insecure_Design/
29. • Le cas trop fréquent • La sécurité applicative par le design • La pratique
30. @hellosct1
31. @hellosct1 Réunir les bons acteurs • Responsables • Développeurs • Commerciaux • Directeurs • ... Brainstorming sécurité
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é
33. @hellosct1 Brainstorming de la sécurité (2/2) • Clarification des ressources • Comprendre les attaquants • Architecture applicative sécurisée © adikts.io
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)
44. @hellosct1 Périmètre d’interventions • Sécurité à chaque étape du projet Garder une sécurité simple
45. @hellosct1 Phase de corrections • Pendant le développement – Laissez le temps des corrections • Utilisez le contrôle automatique – Dans 1 chaîne CI / CD
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é
47. @hellosct1 Trousse à outils • Mise à disposition d’une trousse à outils – VM, IDE… – Script bash • Outils de tests dédié – Owasp
48. @hellosct1 Au quotidien Prévention Détection Réaction
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
50. @hellosct1 Mais Confidentialité Intégrité Disponibilité N'autoriser l'accès qu'aux données pour lesquelles l'utilisateur est autorisé S'assurer que les données ne sont altérées (utilisateurs non autorisés) Les systèmes et les données, disponible pour les utilisateurs autorisés
51. @hellosct1 La plus dangereuse • Contre les développeurs…. Les collaborateurs
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/
54. Christophe Villeneuve @hellosct1 @hellosct1@mamot.fr Merci Sources : - Julien Vehent - Hellosct1