La sécurité applicative par le design

La sécurité applicative par le design
Christophe Villeneuve
@hellosct1
@[email protected]
Capitole du Libre 2022

View Slide

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é
●
Consultant Open Source
●
Dresseur animaux

View Slide

@hellosct1 – Capitole du libre 2022
Aujourd’hui
●
Les projets
●
Logique !!!
●
Bonnes pratiques

View Slide

●
Les projets
●
Logique !!!
●
Bonnes pratiques

View Slide

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)

View Slide

Application web
●
Plusieurs technologies associées
Ajouter un nouvel outil ou une nouvelle envie

View Slide

Les erreurs… Jamais chez moi
●
Ceux ne sont pas des erreurs
– Ceux sont des features
●
Mais un trou de souris…

View Slide

Tout est beau.. Tout est merveilleux

View Slide

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

View Slide

Alors...

View Slide

Allo… Docteur ?
●
De nombreux problèmes → présent
●
Dérive du projet
●
...
Mauvais
DESIGN

View Slide

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

View Slide

Mauvais Design (2/2)
●
Cas fréquents :
– Contrôle des données en entrée
– Mauvaise usage du chiffrement
– Absence de framework
– Secrets en dur dans le code
– Manque de logs
– Système d'authentification faible
– Hétérogénéité des environnements (OS)
– Problème entre architecture et dev

View Slide

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 !!!

View Slide

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

View Slide

●
Les projets
●
Logique !!!
●
Bonnes pratiques

View Slide

Origine des erreurs
La spécification 10 %
Le Design 40 %
Le codage 50 %

View Slide

Détections des erreurs trouvées
Spécification 1 %
Désign 1 %
Codage 1 %
Tests fonctionnels 6 %
Tests systèmes 12 %
En production 20 %

View Slide

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

View Slide

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.

View Slide

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

View Slide

Les principes
●
Aucune norme ou concept
– par des standards
●
Référentiels et bonnes pratiques
– Viega & McGraw
– Owasp
– Nist
– NCSC
– Cliff Berg’

View Slide

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

View Slide

Réunir les bons acteurs
●
Responsables
●
Développeurs
●
Commerciaux
●
Directeurs
●
...
Brainstorming sécurité

View Slide

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é

View Slide

Brainstorming de la sécurité (2/2)
●
Clarification des ressources
●
Comprendre les attaquants
●
Architecture applicative sécurisée
© adikts.io

View Slide

●
Les projets
●
Logique !!!
●
Bonnes pratiques

View Slide


View Slide

1 - Minimiser la surface d’attaque
●
Nouvelle fonctionnalité dans Application
●
Risque augmente
– Impact sur la totalité du projet
●
Objectif d’un développement sécurisé
– Réduire le risque global en diminuant la surface
d’attaque
- Nouvelle fonction
(ex : Recherche avancée)
- Authentification
- Attaque d'inclusion de fichiers

View Slide

2 – Etablir les valeurs par défaut sécurisées
●
Lors du déploiement d’une application
– Sécurité par défaut pour les utilisateurs
→ obtenir une confiance : « Prête à l’emploi »
●
Un utilisateur doit disposer d’un compte avec
certains privilèges et prédéfinis
●
Valeurs par défaut strictes sur les différentes actions
→que l’utilisateur peut faire
→méthode d’enregistrement des données
- Mise à jour d’un mot de passe
régulièrement
- Double Authentification

View Slide

3 – Principe du moindre privilège
●
Application Web
→ Minimum de privilège (ex : accès au contenu)
●
Définition des droits de l’utilisateur
●
Permissions des ressources (CPU, mémoire, réseau...)
●
Permissions du système de fichiers
- Site actualité (beaucoup de contributeurs)
→ Rôle & droits définis
- Si Nouveau contributeur
→ minimum de droits (Auteur / Relecture...?)

View Slide

4 – Défense en profondeur
●
Aborder les risques de différentes manières
– Contrôles de sécurité multiples
●
Meilleure option pour sécuriser une application
– Réduire la surface d’attaque
●
Contrôle d’accès d’un utilisateur
– Validation par différents niveaux
– Contrôles de vérification centralisés
– Obligation d’être connecté et identifié
– Outils de journalisation (log)
- Connexion utilisateur par ses identifiants
Contrôle IP, 2FA, Captcha, Historique de connexions

View Slide

5 – Echec en toute sécurité
●
2 types d’échec :
– Action venant de l’utilisateur
– Echec d’une transaction
●
Problème de traitement d’une transaction
– Un bouton → clic → réponse ?
●
Accès à l’interface utilisateur
●
Les messages de réponse
→ clair et précis
●
Les informations sensibles
→ dans les logs ou BDD
→ pas en clair
- Champ code postal

View Slide

6 – Services tiers
●
Nouvelles fonctionnalités
– On évite de recoder (pour le développeur)
●
Utilisation de Services tiers (API externe, Service…)
●
Risque d’élargir la surface d’attaque
– Suivre leurs actualités
– Vérifier la validité des données envoyées
●
Eviter de donner tous les privilèges
- Ajout VS suppression d’une API
- Fonctions obsolètes

View Slide

7 – Séparation des fonctions
●
Séparation d’une tâche
– Important dans une application
●
Eviter des agissements frauduleux
- Accès administrateurs
Notion différente pour 1 site d’actualité ou marchand

View Slide

8 – Eviter la sécurité par l’obscurité
●
Méthode de sécurité faible
→L’accès n’est pas visible par l’interface
●
Accès plus rapide à un écran de configuration
●
Eviter les accès différents
– Porte dérobée
- modification du port d’une URL

View Slide

9 – Garder la sécurité simple et claire
●
Eviter les architectures trop sophistiquées
●
Si c’est trop complexe
→ Les risques de failles supplémentaires
●
Méthode pas toujours comprise
●
Eviter les fonctions inutiles, fonctions en double
- Nouvelle fonctionnalité dans votre architecture
Celle-ci, existe-t-elle ?

View Slide

10 – Les corrections
●
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é
- Fuite de données
Accès aux informations d’un autre utilisateur
Modification de la valeur d’un cookie
- Piratage d’un compte

View Slide

Au final
●
Impact tous les métiers
●
La sécurité d’une application ajoute une couche
supplémentaire de sécurité à l’ensemble du SI
●
Impact les performances globales
– Une application
– Une infrastructure
●
La sécurité tardive
→ impact sera important

View Slide

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

View Slide

La plus dangereuse
●
Contre les développeurs….
Les collaborateurs

View Slide

En résumé
Prévention
Détection
Réaction

View Slide

@hellosct1
@[email protected]
Merci

View Slide

La sécurité applicative par le design

La sécurité applicative par le design

hellosct1

More Decks by hellosct1

Other Decks in Technology

Featured

Transcript