Security Checked

Présentation du label Security Checked

Le label Security Checked de RandoriSec permet à nos clients d’attester qu’un audit de sécurité a été réalisé sur leur plateforme web (Site institutionnel, API, etc.) et/ou leur application mobile (Android / iOS) et, que le niveau de sécurité à la date de l’audit a été évalué comme satisfaisant.

Afin que le niveau de sécurité soit jugé satisfaisant, il est nécessaire que les conditions suivantes soient respectées :

  • A minima un test d’intrusion a été réalisé sur la cible (web ou mobile). Ce test d’intrusion peut être complété par un audit de code, un audit d’architecture ou un audit de configuration ;
  • Le périmètre défini par le client lors de l’audit a été jugé cohérent par RandoriSec afin d’obtenir une évaluation correcte du niveau de sécurité de la cible ;
  • La plateforme web ne doit souffrir d’aucune vulnérabilité présente dans l’OWASP Top Ten 2017. Pour justifier de la conformité, aucune vulnérabilité ayant un score CVSSv3 supérieur à 4.0 ne doit être identifié lors de l’audit.
  • L’application mobile (Android ou iOS) doit être conforme aux exigences du niveau 1 de l’OWASP Mobile Application Security Verification Standard (MASVS) version 1.1.4. Pour justifier de la conformité, aucune vulnérabilité ayant un score CVSSv3 supérieur à 4.0 ne doit être identifié lors de l’audit.

Le label est attribué au client afin de justifier du niveau de sécurité de la cible auditée. De plus, le label est valable uniquement sur l’année de réalisation de l’audit.


OWASP Top Ten 2017

L’Open Web Application Security Project (OWASP) est une communauté dont la tâche est de permettre aux organisations de développer, acheter et maintenir des applications et des API dignes de confiance. L’OWASP fournit, de façon gratuite et libre, de nombreux outils et des documents de référence concernant la sécurité des applications. Pour plus d’informations, vous pouvez consulter le site de l’OWASP: https://www.owasp.org. Le Top Ten 2017 de l’OWASP permet de sensibiliser les organisations sur les failles les plus courantes et les plus critiques des applications Web.

Pour rappel, l’OWASP Top Ten 2017 recense les risques suivants :

  • A1:2017 - Injection
  • A2:2017 - Broken Authentication
  • A3:2017 - Sensitive Data Exposure
  • A4:2017 - XML External Entities (XXE)
  • A5:2017 - Broken Access Control
  • A6:2017 - Security Misconfiguration
  • A7:2017 - Cross-Site Scripting (XSS)
  • A8:2017 - Insecure Deserialization
  • A9:2017 - Using Components with Known Vulnerabilities
  • A10:2017 - Insufficient Logging & Monitoring


OWASP Mobile Application Security Verification Standard (MASVS)

Le MASVS est un effort communautaire dont le but est d’établir un cadre concernant les exigences de sécurité pour le design, le développement et le test de sécurité des applications mobiles sur iOS et Android.

Pour rappel, l’OWASP MASVS version 1.1.4 recense les sections suivantes pour le niveau 1 (L1) :

  • V1: Architecture and Threat Modelling
  • V2: Data Storage and Privacy
  • V3: Cryptography Verification
  • V4: Authentication and Session Management
  • V5: Network Communication
  • V6: Interaction with the Environment
  • V7: Code Quality and Build Settings


CVSS

Le Common Vulnerability Scoring System (CVSS) est une méthode de calcul permettant de quantifier les caractéristiques intrinsèques d’une vulnérabilité afin d’obtenir un score numérique reflétant sa sévérité. L’échelle suivante est définie pour le score CVSSv3 :

  • Faible : Score CVSSv3 compris entre 0.1 et 3.9
  • Moyen : Score CVSSv3 compris entre 4.0 et 6.9
  • Elevé : Score CVSSv3 compris entre 7.0 et 8.9
  • Critique : Score CVSSv3 compris entre 9.0 et 10.0


Disclaimer

Un audit de sécurité n’est pas une garantie de sécurité ! Les audits de sécurité visent à rechercher les vulnérabilités d’une application ou d’une infrastructure informatique. Ils présentent un état des lieux - sans garantie d’exhaustivité - des vulnérabilités qu’un attaquant pourrait exploiter, à la date et heure de réalisation du test et sur un périmètre donné. De nouvelles vulnérabilités peuvent apparaître au moindre changement de configuration, d’architecture, et surtout si un correctif de sécurité n’est pas appliqué dès publication.