La sécurité applicative par le design

La sécurité applicative par le design
Christophe Villeneuve
@hellosct1
@hellosct1@mamot.fr
le 4 novembre 2021
de la théorie à la pratique

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

@hellosct1
Aujourd’hui
●
Le ‘cas’ trop fréquent
●
●
La pratique

●
Le cas trop fréquent
●
La sécurité applicative
par le design
●
La pratique

@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)

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

@hellosct1
CRM
Intranet
Website
Tracker
Service Auth.
Web Service
Serveur Web
Firewall
Base de données
Access Control
Architecture d'une application Web

@hellosct1
Architecture d'une application Web (2/2)

@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

@hellosct1
Tout est beau.. Tout est merveilleux

@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

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

@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

@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

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

@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

@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

@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.

@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

@hellosct1
3 grands principes
●
Minimiser la surface d’attaque
●
Le moindre privilège
●
La défense en profondeur

@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

@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

@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.

@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

@hellosct1
Documentations (1/2)
●
Aucune norme ou concept
– par des standards
●
Référentiels et bonnes pratiques
– Viega & McGraw
– Owasp
– Nist
– NCSC
– Cliff Berg’

@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/

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

@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é

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

@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

@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

@hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
●
Logs
●
Applications web
●
●
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
●
...

@hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
●
Logs
●
Applications web
●
●
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...)
●
...

@hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
●
Logs
●
Applications web
●
●
Base de données
●
Problèmes courants
●
Captcha
●
Mise en place d’une
2FA
– Push / Pull des
données
●
Pré-Validation

@hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
●
Logs
●
Applications web
●
●
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
●
...

@hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
●
Logs
●
Applications web
●
●
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
●
…

@hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
●
Logs
●
Applications web
●
●
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

@hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
●
Logs
●
Applications web
●
●
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

@hellosct1
Check list
●
Gestion des risques
●
Infrastructure
●
Développement
●
●
Logs
●
Applications web
●
●
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)

@hellosct1
Périmètre d’interventions
●
Sécurité à chaque étape du projet
Garder une sécurité simple

@hellosct1
Phase de corrections
●
Pendant le développement
– Laissez le temps des corrections
●
Utilisez le contrôle automatique
– Dans 1 chaîne CI / CD

@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é

@hellosct1
Trousse à outils
●
Mise à disposition d’une trousse à outils
– VM, IDE…
– Script bash
●
Outils de tests dédié
– Owasp

@hellosct1
Au quotidien
Prévention
Détection
Réaction

@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

@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

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

@hellosct1
C’est pourquoi !!!
●
– 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.

@hellosct1
On continue dans le DevSecOps / SecDevOps...
meetup lizard
https://www.meetup.com/fr-FR/lizard_secu/

@hellosct1
@hellosct1@mamot.fr
Merci
Sources :
- Julien Vehent
- Hellosct1

La sécurité applicative par le design

Contenu connexe

Similaire à La sécurité applicative par le design

Plus de Christophe Villeneuve

La sécurité applicative par le design