stratégies owasp pour développer et exploiter des ...©curité-applicative-owasp-diffusion.pdf ·...
Post on 28-Feb-2019
229 Views
Preview:
TRANSCRIPT
Stratégies OWASP pour
développer et exploiter des
applications sécuritaires
Patrick Leclerc
Président du chapitre OWASP Ville de Québec
patrick.leclerc@owasp.org
ASIQ16 mars 2016
The OWASP Foundation
www.owasp.org
Patrick Leclerc
2
Leader du chapitre
OWASP Ville de Québec
Conseiller en sécurité des actifs
informationnels à La Capitale
22 ans d’expérience
en développement :
• Architecture logicielle et
sécurité
Conseiller en architecture
logicielle désormais dédié à la
sécurité des applications
3
www.owasp.orgMondiale / Non-lucrative / Bénévole / « Open source » / Neutre / Indépendante
Mission : rendre la sécurité applicative visible + vous permettre de prendre desdécisions informées sur les risques de sécurité des applications
Présentations gratuites et orientées principalement pour les gens de développement
et les étudiants:
• Comprendre l'usage de la crypto pour les développeurs
• SSL et les problèmes de validation de certificats dans les applications mobiles
• Ce que vous devriez savoir sur le « Cloud computing »
• Cross-Site Scripting (Avez-vous dit XSS?)
• La sécurité applicative et le cycle de développement
• Développement d’une application sécurisée : étanchéité par le pipeline Web et
le cadre d’application
Partenariats avec OWASP Montréal et le HackFest (développeurs et pen-testers)
• Événements « Capture The Flag » au HackFest (2014, 2015)
• Conférence sur le Top 10 des défenses Web (2012)
Faire connaitre la mission d’OWASP dans les évènements de sécurité et
développement
• ICCE 2014
• CQSI 2015
• HackFest (2012-2016)
• Web à Québec 2016
OWASP Ville de Québec
4
Qu’est ce que la sécurité applicative?
7* Traduit de ISO/CEI 27034-1 (2011) Section 6.1
« OSI Layer 7 » seulement?
Sécurité applicative*: (Définition selon ISO 27034)
« La sécurité des applications est un processus effectué pour appliquer des contrôles et des
mesures aux applications d’une organisation afin de gérer le risque de leur utilisation ».
« Les contrôles et les mesures peuvent être appliquées à l' application elle-même (ses processus, les
composants, les logiciels et résultats), à ses données (données de configuration, les données de
l'utilisateur, les données de l'organisation), et à toutes les technologies, les processus et acteurs
impliqués dans le cycle de vie de l'application ».
ISO/CEI 27034-1 (2011) Section 6.1
“Application Security is a process performed to apply controls and measurements to an organization’s applications in order to manage
the risk of using them.”
“Controls and measurements can be applied to the application itself (its processes, components, software and results), to its data
(configuration data, user data, organization data), and to all technology, processes and actors involved in the application’s life cycle.”
La sécurité applicative ne couvre pas uniquement la portion
logicielle. Elle couvre également tous les contrôles et mesures
impliqués dans le cycle de vie de l’application.
9http://www.informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/
Quelques statistiques
84% des attaques ciblent la couche applicative– Checkmarx 2015
75% des vulnérabilités se retrouvent dans la couche applicative– Checkmarx 2015 (Gartner disait la même chose en 2002…)
70% des applications avaient au moins une vulnérabilité classifiée
dans le top 10 OWASP– Veracode 2015
15% des applications Web ont une vulnérabilité critique ou élevé– Edgescan report 2015
10
Quelques statistiques
11
Dans certains domaines de l’industrie, les applications Web sont
responsables de 35 % des brèches– Verizon DBIR 2015
1 transaction sur 86 des détaillants Web est une tentative de
fraude, une augmentation de 30 % par rapport à 2014– ACI Worldwide 2015
5,3 M$ : Coût moyen d’une perte de données au Canada– « 2015 Cost of Data Breach Study: Canada », Ponemon Institute
250 $ : coût moyen par enregistrement perdu ou volé– « 2015 Cost of Data Breach Study: Canada », Ponemon Institute
PRÉSENTATION
WEB
TRAITEMENT
APPLICATIF
DONNÉESCLIENT
(fureteur)
Protège
le transport
Chiffrement SSL/TLS Pare-feu
Protège
le réseau
Pare-feu
Protège
le réseau
Pare-feu
Protège
le réseau
Protège le
site Web
Serveur Web
et framework
Protège le
traitement
Application
Protège les
données
Base de
données
Le problème avec les applications Web…
13https://securityintelligence.com/the-10-most-common-application-attacks-in-action/
Fire
wa
ll
Syst. exploitation
Web Server
Serveur Applicatif
Fire
wall
Bas
e d
e d
on
née
s
Sys
tèm
es m
issi
on
Web
Ser
vice
s
Rép
erto
ires
Sys
t. R
ess.
Hu
mai
ne
Sys
tèm
e d
e P
aie
Code application
maisonAttaque
applicative
Co
uc
he
ré
se
au
Co
uc
he
ap
plic
ati
ve
Le problème avec les applications Web…
14
Le périmètre de sécurité du passé…
Autrefois:
• Sécurité physique et d’infrastructure autour des applications de missions
(internes)
• Utilisateurs internes, appareils internes sous le contrôle de
l’organisation
INTERNET – MONDIALISATION
Hier:
• Applications internes déployées sur le Web avec +/- les mêmes mesures
• Applications Web => accessibles de tous : usagers légitimes et pirates
informatiques
• Plusieurs applications développées par des développeurs qui en
connaissent peu sur la sécurité
Perte d’étanchéité du périmètre… par les applications Web
15
Le nouveau périmètre
Librairies / plugins externes – Scripts externes –
MOBILES – « BYOD » – CLOUD – INTERNET des OBJETS
Aujourd’hui :
• Applications éparpillées sur le Cloud, chez plusieurs fournisseurs
• Les applications connectées sont partout: mobiles, voitures, « wearable
computers », domotique, appareils électroniques…
Où est le périmètre?
La sécurité applicative devient le
nouveau périmètre
17OWASP AppSecUSA 2014 - Keynote: Renee Guttmann - CISO Perspectives https://www.youtube.com/watch?v=PUKdP_DSLEY
https://www.cigital.com/blog/myth-1-perimeter-security-can-secure-your-applications/
Le TOP 10 des vulnérabilités de sécurité des applications Web
en fonction du RISQUE (Rouge = Impact sévère)
OWASP Top 10 2013
Risques des applications Web
18https://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202013%20-%20French.pdf
2
1
2 semaines d’hacking éthique
10 années-personnes de développement
Lacunes dans la logique d’affaire
Lacunes dans le code
Erreurs de sécurité
21
La fenêtre d’opportunité d’un attaquant est égale à votre fenêtre de disponibilité
Si de votre côté, vous disposez en moyenne que de 20 jours-hommes pour détecter et défendre…
À qui l’avantage?
22
Quelques mesures en PROD…
23
Retirer toutes les applications et services inutiles
S’assurer des bonnes configurations de sécurité
• Vous utilisez encore SSL? https://drownattack.com
Tenir les composantes à jour
• Les versions et correctifs de sécurité de vos serveurs, librairies et logiciels
Tester régulièrement la sécurité de vos sites
• Balayage de vulnérabilités ou tests d’intrusion?
Détecter les attaques
• En moyenne, elles sont découvertes plus de 5 mois plus tard!
Améliorer et corriger rapidement!
Outils automatisés pour faciliter la tâche…
• Analyse statique du code (SAST)
• Analyse dynamique des requêtes (DAST)
• Analyse hybride (IAST)
Analyses et révision de code
25
Révision de code manuelle
pour les composants
stratégiques
Évidence:
Prise en charge des enjeux de sécurité tout au long du cycle de
développement
Approche prôné par OWASP, NIST, Microsoft et plusieurs autres
organisations
Observation:
Les coûts reliés aux
corrections des risques
de sécurité augmentent
de façon exponentiel
quand les corrections
sont découvertes
tardivement dans le cycle
de développement…
Sécurité dans le cycle de développement
27Source: Official (ISC)2 Guide to the CSSLP
• Approche : No « one-size-fits-all »
• Adaptation selon les risques de l’organisation
• Adaptation selon le processus de développement en
place
Les organisations changent lentement
Changements progressifs et itératifs
• Former et sensibiliser avec un contenu adapté aux gens
• Objectifs pragmatiques et mesurables
• Les améliorations doivent subsister
30
Éléments à savoir…
SAMM (Software Assurance Maturity Model)
31https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model
• Méthodologie aidant à définir l’approche idéale de prise en charge
de la sécurité applicative en fonction du contexte particulier et des
risques de l’organisation
• Couvre tout le cycle de vie
des applications
• Modèles de prise de maturité
par industries
• Très logique, très
pragmatique
4 domaines
• 3 disciplines par domaines de sécurité, chaque discipline
incorpore des activités de sécurité (environ de 5-7 chacune)
• Les disciplines couvrent toute la surface de l’assurance sécurité
des applications
SAMM – Disciplines de sécurité
32https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model
• Chaque discipline définit 3 niveaux de maturité établis et
la stratégie pour les atteindre.
• Un questionnaire aide à établir quel est le niveau de
maturité de l’organisation dans chacune des disciplines
• 3 niveaux de maturité… et 1 d’immaturité…:
Discipline non établie
Compréhension initiale, en mode réactif
Monté en puissance, en mode proactif
Maitrise complète, en mode efficience
SAMM – Niveaux de maturité
33https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model
SAMM – Questionnaire de maturité
34https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model
SAMM – Approche itérative
35
Amélioration itérative (phase)
On définit la stratégie et les
métriques
• Enchainement logique en fonction
des interrelations
• Objectifs mesurables découpés en
phases
• En fonction de la maturité désirée
• Modèles de plan de prise en charge
en fonction du type d’industrie
Intégration d’activités de sécurité
Formation
Programme
assurance
sécurité
Classification
des données et
applications
Guide politiques
et conformité
Rôles et
responsabilités
Modélisation
des menaces
Exigences
de sécurité
Architecture
de sécurité
Revue de
conception
Vérifications
du code
Tests
d’intrusion
périodiques
Guide sécurité
opérationnelle
Tests
d’intrusion
préproduction
Gestion des
vulnérabilités
Durcissement
environnement
36
• Appui de la direction du développement et des domaines
d’affaires
• Participation et collaboration de ressources
compétentes du développement
• Former, sensibiliser, former, sensibiliser, former…
• Définir les rôles et responsabilités
• Communiquer d’où on part et où l’on va
• Outiller les ressources en fonction de leurs tâches
• Amélioration continue (le paysage de la sécurité change)
37
Quelques facteurs de succès
OWASP Application Security Guide For CISOs
39https://www.owasp.org/index.php/File:Owasp-ciso-guide.pdf
Guide réalisé pour les CISO (Chief Information Security Officer)
1. Critères d'orientation pour les investissements en sécurité
applicative
• Conformité, gouvernance, audits, quantification des risques, bénéfices des mesures…
2. Critères de gestion des risques de sécurité applicative
• Priorisations des vulnérabilités, menaces et contremesures
3. Programme de sécurité applicative
4. Métriques de gestion de risques et
d’investissement en sécurité applicative
Programme
assurance
sécurité
Guide politiques
et conformité
OWASP Application Security Verification Standard
40https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
Exigences
de sécurité
OWASP Cheat Sheets (Aides mémoire)
41https://www.owasp.org/index.php/Cheat_Sheets
Modélisation
des menaces
Architecture
de sécurité
Tests
d’intrusion
Durcissement
environnementVérifications
du code
Revue de
conception
OWASP Enterprise Security API
Custom Enterprise Web Application
Enterprise Security API
Au
the
nti
ca
tor
Use
r
Acce
ssC
on
tro
lle
r
Acce
ssR
efe
ren
ce
Ma
p
Va
lid
ato
r
En
co
de
r
HT
TP
Uti
liti
es
En
cry
pto
r
En
cry
pte
dP
rop
ert
ies
Ra
nd
om
ize
r
Ex
ce
pti
on
Ha
nd
lin
g
Lo
gg
er
Intr
usio
nD
ete
cto
r
Se
cu
rity
Co
nfi
gu
rati
on
Existing Enterprise Security Services/Libraries
« Framework » JAVA* offrant plusieurs fonctions de sécurité usuelles
! nouvelle version disponible depuis février 2016 !
*Malheureusement les autres langages manquent un peu d’amour
42https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
Architecture
de sécurité
OWASP Dependency Check
Utilitaire permettant d’analyser les applications et les librairies externes et vérifier si
elles contiennent des vulnérabilités connues dans la base de données du NIST
Java
.NET
Ruby
Node.js
Python
C/C++
43https://www.owasp.org/index.php/OWASP_Dependency_Check
Gestion des
vulnérabilités
OWASP AppSensor
Technique avancée:
• Méthodologie et cadre conceptuel pour intégrer des mécanismes de détection
d'intrusion et de réponse automatique dans les applications
• Détection en fonction de la logique de l’application
• Réponses: de l’alertage à la déconnexion (plus d’une douzaine d’actions décrites)
44https://www.owasp.org/index.php/OWASP_AppSensor_Project
Durcissement
environnement
Architecture
de sécurité
OWASP Testing Guide
45https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf
Revue de
conception
Vérifications
du code
Tests
d’intrusion
périodiques
Tests
d’intrusion
OWASP ZAP
46https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Vérifications
du code
Tests
d’intrusion
OWASP OWTF (Web Testing Framework)
47
Environnement pour faciliter et rendre plus
efficace les tests d’intrusion applicatifs
• Orchestre le lancement de plusieurs outils sur
plusieurs site
• Collecte et organise les résultats sous forme
d’un rapport interactif
https://www.owasp.org/index.php/OWASP_OWTF
Tests
d’intrusion
OWASP Training projects
Plateforme d’apprentissage de sécurité applicative
• OWASP Security Shepherd
• Applications Web et mobiles
• Leçons et « challenges »
• 17 niveaux (de novice à expert)
• Parfait pour les classes et les tournois CTF
• OWASP WebGoat
• Applications délibérément non sécurisées
• Plus de 30 leçons
• Leçons et indices
• « Challenges » réalistes
48https://www.owasp.org/index.php/OWASP_Security_Shepherd https://www.owasp.org/index.php/Webgoat
Tests
d’intrusion
Formation
OWASP ModSecurity Core Rule Set
49https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
INDICATIONS : Pour le soulagement rapide de certains symptômes de
vos applications Web affectées par certaines vulnérabilités applicatives.
Offre une couche de protection supplémentaire pour défendre les
applications Web.
POSOLOGIE : Incorporer le « Core Rule Set » à vos pares-feu
« ModSecurity ». Réadministrer sans tarder à chaque mise à jour.
INGREDIENTS ACTIFS: Ensemble de règles de détection d’attaques pour
le pare-feu applicatif « open source » et multiplateforme « ModSecurity ».
MISE EN GARDE : Peut procurer un faux sentiment de sécurité. Ne
constitue pas un remède à la correction de vos applications.
Durcissement
environnement
50
1. Le PÉRIMÈTRE de sécurité du
passé N’EST PLUS ÉTANCHE…
« La sécurité applicative doit
définir le nouveau périmètre »
2. Nécessité d’INTÉGRER la
sécurité applicative le PLUS TÔT
POSSIBLE dans le cycle de
développement…
top related