Passer au contenu principal
Mettre en ligneLangue (FR)Assistance clientèle
BusinessMobileMédias sociauxMarketingTechnologieArt & PhotosCarrièreDesignFormationPrésentations et discours publicsGouvernement et associations à but non lucratifSantéInternetDroitDirection et managementIndustrie automobileIngénierieLogicielsRecrutement & RHCommerce de détailVentesServicesSciencesPetites entreprises & entrepreunariatAlimentationEnvironnementÉconomie & financeDonnées & analysesRelations avec les actionnairesSportsSpirituelActualités & PolitiqueVoyagesDéveloppement personnelImmobilierDivertissement et humourSanté & MédecinePériphériques & matérielMode de vie
Laurie-Anne Bourdain, profile picture
Téléchargé parLaurie-Anne Bourdain
PPTX, PDF2,522 vues

Un peu de sécurité dans ce monde de Kiwi

Le document traite de la gestion des risques en matière de sécurité informatique, en spécifiant les menaces comme le spoofing, le tampering et le denial of service. Il aborde également des bonnes pratiques pour atténuer les risques, telles que l'authentification des utilisateurs, la gestion des autorisations et l'utilisation de requêtes sécurisées pour prévenir les injections SQL. Enfin, il souligne l'importance des sauvegardes et de la continuité des activités face aux cyberattaques.

Présentations et discours publics◦
Sujets connexes:
Internet Security•
Téléchargé 10 fois
UN PEU DE SÉCURITÉ DANS CE MONDE DE KIWI Laurie-Anne Bourdain Kiwi Party 2014 1
LA SÉCURITÉ RÉPONDS AUX RISQUES Confidentialité Intégrité Disponi- bilité 2
QU’EST-CE QUE JE VOUS SERT? Gestion de Risque • Analyse • Réponse • Évaluation On the Web again • Les Menaces de l’Internet • Comment les Mitiger • Quelques bonnes pratiques Questions 3
LES BASES DE LA GESTION DE RISQUES 4
UN CYCLE SANS FIN Gestion de Risque Analyse RéponseÉvaluation 5
S.T.R.I.D.E. (PROGRÈS) • Se faire passer pour quelqu’un ou quelque chose que l’on n’est pas. • Peut être utilisé pour modifier des données, un DoS… Spoofing • Modifier quelque chose sans en avoir le droit. • Le « defacing » en est l’exemple le plus visible.Tampering • Rejet de Responsabilité. • Affirmer ne pas avoir fait quelque chose (vrai ou pas). • Sert généralement à camoufler un « spoofing » ou « tampering ». Repudiation • Accéder à et publier des informations (généralement sensibles ou confidentielles). • Le cas Snowden est un bon exemple. Information Disclosure • Attaque qui a pour but d’empêcher les utilisateurs légitimes d’utiliser un service. • En le crashant, le ralentissant ou en saturant sa mémoire. Denial of Service • (Se) donner plus d’accès à un système. • Peut permettre un « tampering » ou « information disclosure » Elevation of Privilege 6
IDENTIFIER SES RISQUES Tous les sites ne sont pas exposés aux mêmes risques, mais il y a de grandes tendances (voir OWASP Top 10). Les questions à se poser:  Qu’est-ce qui peut valoir le coup d’attaquer mon site?  Quelle est ma visibilité?  Est-ce que des concurrents (ou moi-même) ont subit des attaques?  Quelles sont mes périodes critiques (fin de mois/d’année, release d’un super produit, grande annonce…)? Ne pas négliger ce qui semble improbable. 7
LA RÉPONSE… N’EST PAS 42 Mitiger Eliminer Transférer Accepter Risque 8
NE PAS TROP EN FAIRE 0 10 20 30 40 50 60 0 20 40 60 80 100 Coût des risques Coût des mesures de mitigation de risques Équilibre 9
ÉVALUER LES RISQUES Pour évaluer les risques on utiliser généralement la formule suivante: PPA = PPI * FA Ou: PPA : Prévision de Perte Annuelle PPI : Prévision de Perte Isolée FA : Fréquence Annuelle 10
ÉVALUER LES RISQUES Impact Faible Moyen Grave Catastrophique Probabilité Élevé Moyenne Faible Très faible 11
ON THE WEB AGAIN 12
OWASP TOP 10 OWASP Top 10 2013 A1 Injection A2 Broken Authentication & Session Management A3 Cross-Site Scripting (XSS) A4 Insecure Direct Object References A5 Security Misconfiguration A6 Sensitive Data Exposure A7 Missing Function Level Access Control A8 Cross-Site Request Forgery (CSRF) A9 Using Unknown Vulnerable Components A10 Unvalidated Redirects and Forwards 13 Plus d’info: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
LES UTILISATEURS  Identification, authentification et autorisation: Identifier: demander qui est l’utilisateur Authentifier: vérifier qui est l’utilisateur Autoriser: donner des accès à l’utilisateur L’authentification et les autorisations de l’utilisateur doivent être vérifiée pour chacune de ses actions. Les autorisations doivent être données selon les principes du « least privilege » et du « Need-to-Know »  Non-repudiation: Être capable d’identifier l’auteur des problèmes. Toutes les actions utilisateurs doivent être loguées. Ces logs doivent être protégés en écriture. 14
LES UTILISATEURS, BIS  Injections SQL: Vérifier le type de données si possible; Échapper les caractères spéciaux (mysqli_real_escape_string()); Utiliser des requêtes pré-formatées:  $stmt = $dbh->prepare("SELECT * FROM users WHERE USERNAME = ? AND PASSWORD = ?"); $stmt- >execute(array($username, $password));  La requête pré-formatée n’accepte que les données attendues et est plus rapide (quand il y a plusieurs requêtes identiques à exécuter). 15
LE DÉVELOPPEUR  Porte Dérobées (Backdoor) / Porte de Debug Porte Dérobée = Pas Bien Porte de Debug = Pas Bien en Production Les portes dérobées sont des moyens d’entrée non documentés, sans mot de passe et/ou contournant les mesures de sécurité d’une application. Les portes de debug sont la même chose, mais leur but est d’offrir, lors du développement, des accès facile pour tester les fonctionnalités d’une application. Elles doivent toujours être supprimées avant de déployer en production. L’utilisateur « admin » (mdp = admin) est une backdoor. 16
LE DÉVELOPPEUR, BIS  Version et Documentation Versionner son code permet de repartir sur une base saine lors de développements futurs. Éviter les développement à La RACHE©®™  Patcher Toujours utiliser les dernières versions de Biblio, API… Patchez également vos softwares et serveurs.  Testez, Testez, Testez ! 17
L’HÉBERGEMENT  Backup Vérifiez quelle est la politique de backup de votre hébergeur. Comparez la à vos besoins. Si nécessaire, faites les backups vous-même  Politique de destruction du matériel Savez-vous ce qu’il advient des disques qui ont hébergé vos données lorsqu’ils sont en fin de vie?  DoS Dans la plupart des cas, les attaques DoS seront gérées par votre hébergeur et son ISP.  Continuité Si la continuité est critique pour votre activité, prévoyez un plan de secours (autre hébergeur). 18
LES AUTRES  Il existe des attaques contre lesquelles, on ne peux rien faire. Sauf éduquer les utilisateurs et signaler les attaques en cours. Phishing Dangling Pointer (Lien moisi) 19
QUESTIONS ? 20