Sécuriser les applications et les données

Objectif d'apprentissage 5.1.A : Expliquer comment les adversaires peuvent exploiter les vulnérabilités applicatives et de fichiers pour provoquer des pertes, des dommages, des perturbations ou des destructions.

• 5.1.A.1 Un adversaire peut lire tout fichier non chiffré s'il a accès à l'appareil ou au disque stockant les fichiers.
• 5.1.A.2 Les ordinateurs ont des utilisateurs standards et des utilisateurs administrateurs. Les utilisateurs administrateurs ont accès aux paramètres de contrôle du système et peuvent généralement accéder à n'importe quels fichiers ou applications sur un système. Si des utilisateurs réguliers se voient accorder des privilèges administrateurs sur un ordinateur et qu'un adversaire peut compromettre le compte d'un utilisateur, alors l'adversaire aura des privilèges élevés sur le système.
• 5.1.A.3 Lorsque les paramètres de contrôle d'accès sont faiblement configurés, de nombreux utilisateurs ont souvent la permission de visualiser et parfois même de modifier des fichiers sur un système. Les adversaires peuvent tirer parti de paramètres de contrôle d'accès faibles pour voler ou détruire des fichiers ou perturber une application.

Objectif d'apprentissage 5.1.B : Expliquer comment les attaques applicatives exploitent les vulnérabilités.

• 5.1.B.1 Les applications sont des programmes qui exécutent des instructions sur des ordinateurs ; ce sont des données exécutables. Certaines applications s'exécutent localement sur l'ordinateur d'un utilisateur, tandis que d'autres applications, comme les applications web, s'exécutent sur un serveur et sont accessibles par les utilisateurs via un réseau.
• 5.1.B.2 De nombreuses applications prennent des entrées utilisateur via des champs de saisie ouverts où les utilisateurs peuvent taper des caractères (par exemple, des lettres, des chiffres, de la ponctuation). Les développeurs devraient inclure des vérifications d'entrée utilisateur dans leur application, telles que des entrées numériques lorsqu'on demande un nombre d'articles, pour s'assurer que l'entrée utilisateur correspond à ce qui est attendu ; l'application doit rejeter les entrées en dehors des paramètres attendus. Ce processus de vérification que l'entrée utilisateur répond aux critères attendus avant son traitement est appelé validation des données. Les applications qui échouent à valider l'entrée utilisateur sont vulnérables aux attaques de type injection, où les adversaires insèrent des chaînes de caractères inattendues dans les champs de saisie pour altérer le comportement d'un programme.
• 5.1.B.3 Le langage SQL (Structured Query Language) est un langage informatique utilisé pour demander des informations aux bases de données et apporter des modifications aux bases de données ou aux entrées des bases de données. Les applications qui interrogent une base de données en utilisant des entrées non validées ou non nettoyées provenant des utilisateurs sont vulnérables.
• 5.1.B.4 Une attaque d'injection SQL place des commandes SQL et des caractères de contrôle dans un champ de saisie utilisateur dans une application, ce qui peut entraîner une atteinte à la confidentialité en faisant retourner à l'application plus d'informations qu'elle ne devrait, ou une atteinte à l'intégrité en modifiant ou en supprimant des données dans la base de données.
• 5.1.B.5 Les sites Web sont écrits en langage HTML (hypertext markup language), et de nombreux sites utilisent Javascript pour créer du contenu dynamique sur les sites Web ou les applications Web. Comme les commandes Javascript s'exécutent dans le navigateur de l'utilisateur visitant le site, ces commandes peuvent accéder aux données sensibles stockées dans le navigateur, telles que les noms d'utilisateur, les mots de passe et les clés cryptographiques.
• 5.1.B.6 Une attaque XSS (Cross Site Scripting) injecte du code malveillant dans un site Web que le navigateur de l'utilisateur exécute ensuite. Le code malveillant peut être intégré dans un lien cliqué par l'utilisateur (une attaque XSS de Type I ou Reflectée) ou il peut être inséré sur un site Web via un champ de commentaire, un message de forum ou un journal de visiteur, ce qui affecterait tout utilisateur visitant ce site Web (une attaque XSS de Type II ou Stockée).
• 5.1.B.7 Lorsqu'elles prennent une entrée utilisateur, cette entrée est écrite dans un tampon. Un tampon est une section désignée de la mémoire informatique avec une taille fixe. Si la quantité de données saisies par l'utilisateur dépasse la taille du tampon, elle peut déborder vers des emplacements mémoire adjacents et écraser d'autres parties de la mémoire de l'ordinateur.
• 5.1.B.8 Une attaque de débordement de tampon alimente plus de données dans la mémoire que ce qui était alloué, ce qui peut provoquer un crash du système ou l'exécution de code en dehors du cadre de la politique de sécurité d'un programme, permettant ainsi effectivement à l'adversaire d'effectuer des actions non autorisées sur un ordinateur, telles que l'accès, la modification ou la suppression de fichiers.
• 5.1.B.9 Les fichiers qui exécutent les applications web sont stockés dans des répertoires sur des serveurs. Lorsqu'ils accèdent à des applications web, leurs navigateurs envoient des requêtes GET en utilisant le protocole de transfert hypertexte (HTTP). Une requête GET accède à un fichier quelque part dans le système de fichiers du serveur.
• 5.1.B.10 Dans une attaque par traversal de répertoire, les adversaires modifient les URL et les requêtes GET pour tenter d'accéder à des données sensibles (par exemple, noms d'utilisateur et mots de passe) sur le système de fichiers d'un serveur.
  • Exemples illustratifs pour 5.1.B.10 :
    • Un serveur web stocke les images d'un site qu'il héberge dans le répertoire /var/www/images/. Un adversaire modifie une URL demandant une image pour obtenir ../../../etc/passwd. Le .. permet de remonter d'un répertoire dans le système de fichiers ; ainsi, trois .. consécutifs renvoie le chemin vers la racine, et de là, l'adversaire tente d'accéder au fichier passwd qui contiendrait une liste de tous les utilisateurs autorisés sur l'appareil.

Objectif d'apprentissage 5.1.C : Évaluer et documenter les risques liés aux vulnérabilités des applications et des données.

• 5.1.C.1 Les risques pour la sécurité des données peuvent impliquer une atteinte à la confidentialité lorsque des personnes non autorisées peuvent accéder à des données sensibles, une atteinte à l'intégrité lorsque des données peuvent être manipulées ou altérées par rapport à leur état prévu, et une perte de disponibilité lorsque des données peuvent être détruites ou chiffrées pour empêcher d'autres personnes de y accéder.
• 5.1.C.2 Les hauts risques dus aux vulnérabilités des données concernent souvent des données très sensibles (par exemple, des données régies par des lois ou des réglementations) qui pourraient être compromises par une exploitation très probable.
  • Exemples illustratifs pour 5.1.C.2 :
    • L'entreprise développant le prochain réacteur qui sera utilisé par l'Air Force dans ses avions stocke les spécifications techniques du réacteur sur un disque non chiffré.
• 5.1.C.3 Les risques moyens dus aux vulnérabilités des données concernent souvent des données sensibles ne disposant pas d'un chiffrement suffisamment fort ou de contrôles d'accès assez stricts.
  • Exemples illustratifs pour 5.1.C.3 :
    • Une entreprise stocke les RPI (renseignements personnels identifiables) de ses clients dans un tableur, et ce tableur est chiffré avec une petite clé.
• 5.1.C.4 Les faibles risques dus aux vulnérabilités des données concernent souvent des informations moins sensibles étant chiffrées avec des clés plus courtes ou ayant des contrôles d'accès qui ne sont pas assez stricts.
  • Exemples illustratifs pour 5.1.C.4 :
    • Le PDG d'une organisation stocke ses mémos privés destinés à son personnel exécutif sur un lecteur partagé de l'entreprise qui est non chiffré et ne dispose d'aucun contrôle d'accès.

Objectif d'apprentissage 5.2.A : Expliquer comment l'état ou la classification des données impacte le type et le degré de sécurité appliqué à ces données.

• 5.2.A.1 Les organisations mettent en œuvre des contrôles de sécurité spécifiques pour se conformer aux exigences légales basées sur les types de données qu'elles collectent, stockent, traitent et transmettent.
• 5.2.A.2 Les données peuvent être classifiées selon leur état.
  • Les données au repos sont stockées sur un disque. Il est important de protéger le disque physique stockant les données contre la destruction ou le vol. Les données au repos peuvent également être chiffrées afin que si un adversaire les vole, il ne puisse pas immédiatement lire les données.
  • Les données en transit sont envoyées d'un appareil à un autre. Si les données sont transférées via un support physique (par exemple, des câbles), il est important de protéger le support. Les données en transit peuvent également être chiffrées afin que si un adversaire les intercepte, il ne puisse pas immédiatement lire les données.
  • Les données en cours d'utilisation sont traitées par un logiciel ou une personne. Des contrôles d'accès peuvent être utilisés pour limiter qui ou quoi a la capacité d'utiliser les données de différentes manières (par exemple, afficher ou modifier). Les données doivent être déchiffrées pour être utilisées.
• 5.2.A.3 Les organisations catégorisent souvent les données selon leur sensibilité et priorisent un degré de sécurité plus élevé pour les informations plus sensibles.
• 5.2.A.4 Les lois et réglementations peuvent exiger que certains types de données soient stockés, transmis et traités conformément à des règles spécifiques.
  • Les renseignements personnels identifiables (RPI/PII) sont toutes les données permettant d'identifier une personne et incluent (mais ne se limitent pas à) : nom, signature, numéro de téléphone, adresse, données biométriques (par exemple, empreintes digitales), numéro de sécurité sociale, date de naissance et adresse e-mail. La protection de ces données est couverte par de nombreuses lois mais notamment The Privacy Act of 1974 et, pour les enfants de moins de 13 ans, le Children’s Online Privacy Protection Act of 1998.
  • Les informations de santé protégées (PHI) sont toutes les données relatives à la santé d'un individu, à son traitement, au paiement des soins de santé à tout moment et incluent (mais ne se limitent pas à) : résultats de tests, dossiers de traitement, dossiers hospitaliers, notes de visite chez le médecin et dossiers de paiement des prestataires de soins. La protection des PHI est incluse dans le Health Insurance Portability and Accountability Act of 1996.
  • Les informations de carte de paiement (PCI) sont les données collectées par les organisations pour traiter les paiements par cartes (par exemple, cartes de crédit) et incluent les éléments suivants : nom, numéro de compte, date d'expiration, adresse et code CVV. La protection de ces données est réglementée par le Payment Card Industry Data Security Standard (PCI-DSS).
• 5.2.A.5 Les organisations qui collectent des données réglementées les étiquettent et disposent de politiques se conformant aux exigences légales ou réglementaires pour le stockage sécurisé, la transmission et le traitement de ces données.

Objectif d'apprentissage 5.2.B : Identifier les contrôles managériaux liés à la sécurité des applications et des données.

• 5.2.B.1 Une politique de cryptographie décrira les protocoles de chiffrement et les paramètres de clé acceptables pour une organisation et peut inclure :
  • Une liste des algorithmes de chiffrement approuvés pour des usages spécifiques
  • Longueurs minimales ou maximales de clés
  • Exigences et paramètres de génération de clés cryptographiques
  • Exigences de stockage de clés cryptographiques
• 5.2.B.2 Une politique de sécurité des applications web définira les exigences et les paramètres pour tester et atténuer les vulnérabilités des applications web dans une organisation, et elle peut inclure :
  • Paramètres pour le moment où une application est soumise à une évaluation de sécurité
  • Échéanciers pour la résolution des vulnérabilités selon le niveau de risque
  • Paramètres pour la manière dont une évaluation de sécurité des applications doit être effectuée (par exemple, en utilisant des outils spécifiques ou selon des cadres spécifiques)

Objectif d'apprentissage 5.2.C : Déterminer un modèle de contrôle d'accès approprié pour protéger les applications et les données.

• 5.2.C.1 Le contrôle d'accès impose quels utilisateurs ou applications (appelés sujets) peuvent accéder, modifier, ajouter ou supprimer (appelées opérations) quels fichiers ou applications (appelés objets). Les modèles de contrôle d'accès décrivent comment déterminer quels sujets ont quel type d'accès à quels objets.
• 5.2.C.2 Le contrôle d'accès basé sur les rôles (RBAC) attribue chaque sujet à un rôle et définit quels rôles ont quel type d'accès à quels objets.
  • Exemples illustratifs pour 5.2.C.2 :
    • Un exemple de rôle dans une entreprise pourrait être « comptable », et un type d'objet pourrait être le logiciel de paie. Le contrôle d'accès basé sur les rôles pourrait être utilisé pour s'assurer que seuls les sujets assignés au rôle de « comptable » ont accès à l'objet logiciel de paie.
• 5.2.C.3 Le contrôle d'accès basé sur les règles (RuBAC) vérifie un ensemble de règles pour déterminer quel type d'accès un sujet devrait avoir pour un objet spécifique, puis autorise ou refuse des types d'accès en fonction des règles. Ce modèle de contrôle d'accès est généralement superposé à un autre modèle de contrôle d'accès.
  • Exemples illustratifs pour 5.2.C.3 :
    • Il existe une règle interdisant aux sujets (même ceux qui auraient normalement accès) d'accéder à une certaine base de données (l'objet) en dehors des heures de travail locales. Lorsqu'un sujet tente d'accéder à la base de données, même s'il est autorisé à y accéder, il se verra refuser l'accès si c'est en dehors du temps désigné par la règle.
• 5.2.C.4 Le contrôle d'accès discrétionnaire (DAC) donne aux sujets individuels la capacité de définir le type d'accès que d'autres sujets ont sur les objets qu'ils possèdent. Dans les modèles DAC, certains sujets sont désignés comme administrateurs ou super-utilisateurs, et ils ont la capacité de contourner les contrôles d'accès établis par d'autres sujets.
  • Exemples illustratifs pour 5.2.C.4 :
    • Bob crée un fichier (un objet) et décide de donner à Alice la permission de modifier le fichier, de donner à Frank la permission de voir le fichier uniquement, et de refuser l'accès à ce fichier à tous les autres.
• 5.2.C.5 Le contrôle d'accès obligatoire (MAC) suit des règles strictes concernant les types d'accès que chaque niveau de sujet a pour les objets situés au-dessus de son niveau, à son niveau ou en dessous de son niveau. Les niveaux de sujet et d'objet sont assignés par un administrateur externe.
• 5.2.C.6 Le modèle Bell-LaPadula est un modèle MAC souvent utilisé par les gouvernements et les organisations militaires pour contrôler la sécurité des informations. Ce modèle possède les deux propriétés importantes suivantes :
  • i. La Propriété Simple stipule que les sujets ne peuvent pas lire les objets situés au-dessus de leur niveau.
  • ii. La Propriété * (Étoile) stipule que les sujets ne peuvent pas écrire dans les objets situés en dessous de leur niveau.
  • Ces règles prises ensemble sont souvent résumées par « write up, read down » (WURD).
• 5.2.C.7 Le principe de moindre privilège est l'idée que les entités devraient recevoir exactement autant d'accès qu'elles ont besoin pour effectuer leur fonction et aucun de plus.

Objectif d'apprentissage 5.2.D : Configurer les paramètres de contrôle d'accès sur un système basé sur Linux.

• 5.2.D.1 L'autorisation est le fait qu'une entité obtienne la permission d'avoir un certain type d'accès à une ressource. Des contrôles d'accès sont mis en place pour contrôler quels utilisateurs ont quels types d'accès à quelles données.
• 5.2.D.2 Il existe trois types d'accès à un fichier sous Linux qui peuvent être définis, et ils viennent toujours dans l'ordre suivant :
  • i. L'accès en lecture permet à un utilisateur de voir le contenu d'un fichier.
  • ii. L'accès en écriture permet à un utilisateur de modifier un fichier.
  • iii. L'accès en exécution permet à un utilisateur d'exécuter un fichier binaire tel qu'un programme.
  • Ceux-ci sont abrégés rwx, respectivement. Si un utilisateur n'a que les permissions de lecture et d'exécution (pas d'écriture), cela s'affichera comme r-x. Le symbole - indique l'absence de cette permission.
• 5.2.D.3 Il existe trois entités par défaut pour lesquelles les permissions sont définies et toujours dans cet ordre : (1) le propriétaire du fichier, (2) le groupe du fichier, et (3) tous les autres utilisateurs. Les trois ensembles s'affichent sans espaces (par exemple, rwxrwxrwx).
• 5.2.D.4 Pour afficher les paramètres d'autorisation actuels d'un fichier, utilisez la commande ls -l, qui affichera les paramètres actuels pour les entités par défaut. S'il y a un symbole + à la fin des autorisations, cela signifie que d'autres autorisations ont été définies pour ce fichier et qu'elles peuvent être visualisées avec la commande getfacl.
• 5.2.D.5 Pour modifier les paramètres d'autorisation d'un fichier, utilisez la commande chmod. Cette commande peut être utilisée avec la méthode numérique ou la méthode symbolique.
• 5.2.D.6 Pour utiliser chmod dans la méthode numérique, la syntaxe est chmod ### filename. Chacun des trois ### représente l'une des trois entités mentionnées ci-dessus (le propriétaire, le groupe, les autres utilisateurs non membres du groupe).
  • Le premier # = le propriétaire
  • Le deuxième # = le groupe
  • Le troisième # = les autres utilisateurs non membres du groupe
  • L'autorisation pour chaque entité est déterminée en additionnant les valeurs des types d'accès à accorder :
  • 0 = aucune autorisation
  • 1 = exécution
  • 2 = écriture
  • 4 = lecture
  • Par conséquent, 3 définit l'autorisation d'écriture et d'exécution, 5 définit l'autorisation de lecture et d'exécution, 6 définit l'autorisation de lecture et d'écriture, et 7 définit l'autorisation de lecture, d'écriture et d'exécution.
  • Exemples illustratifs pour 5.2.D.6 :
    • La commande chmod 750 test définirait les autorisations pour le propriétaire : lecture, écriture et exécution ; pour le groupe : lecture et exécution ; et pour tous les autres : aucun accès.
    • La commande chmod 543 test définirait les autorisations pour le propriétaire : lecture et exécution ; pour le groupe : lecture seule ; et pour tous les autres : écriture et exécution.
    • La commande chmod 777 test définirait les autorisations pour les trois entités : lecture, écriture et exécution pour le fichier test.
• 5.2.D.7 Pour utiliser chmod dans la méthode symbolique, la syntaxe est chmod entity +(ou –) permission filename. Les entités sont l'utilisateur propriétaire, le groupe et les autres utilisateurs non membres du groupe. Chaque entité est représentée par une seule lettre.
  • u = utilisateur propriétaire
  • g = groupe
  • o = autres
  • a = tous
  • L'autorisation peut être ajoutée ou retirée à n'importe quelle combinaison d'entités.
  • • = ajouter l'autorisation
  • – = retirer l'autorisation
  • Les autorisations qui peuvent être définies sont la lecture, l'écriture et l'exécution.
  • r = lecture
  • w = écriture
  • x = exécution
  • Les entités et les autorisations peuvent être combinées dans une seule commande. Pour ajouter les autorisations de lecture et d'exécution pour le groupe et l'utilisateur propriétaire pour un fichier nommé testfile, la commande serait chmod ug+rx testfile.

Objectif d'apprentissage 5.3.A : Expliquer comment le chiffrement peut être utilisé pour protéger les fichiers.

• 5.3.A.1 Le but de la cryptographie est de cacher des informations. Un algorithme de cryptographie définit un processus de chiffrement et de déchiffrement des informations. Le chiffrement est le processus de cachage des informations, et le déchiffrement est le processus d'inversion du chiffrement pour récupérer les informations originales.
• 5.3.A.2 Un algorithme de chiffrement définit un processus de combinaison des informations à chiffrer avec une clé prédéfinie. Les informations à chiffrer sont appelées le texte en clair. La sortie de l'algorithme de chiffrement est appelée le texte chiffré.
• 5.3.A.3 Le nombre de clés possibles pouvant être utilisées dans un algorithme de chiffrement est appelé l'espace de clés. Plus l'espace de clés est grand, plus il faudra de temps à un adversaire pour découvrir la bonne clé par hasard.
• 5.3.A.4 Les algorithmes de cryptographie sont classés selon qu'ils utilisent une clé ou deux clés.
  • Les algorithmes de chiffrement symétriques utilisent la même clé pour chiffrer et déchiffrer les informations.
  • Les algorithmes de chiffrement asymétriques utilisent deux clés différentes — une pour chiffrer les informations et l'autre pour les déchiffrer.
• 5.3.A.5 Les algorithmes de cryptographie sont également classés selon qu'ils traitent les informations bit par bit ou par blocs de taille fixe de bits.
  • Le chiffrement par bloc traite les informations par blocs de taille fixe appelés blocs, produisant un bloc de sortie pour chaque bloc d'entrée.
  • Le chiffrement par flux traite les informations d'entrée de manière continue, produisant une sortie élément par élément.

Objectif d'apprentissage 5.3.B : Appliquer des algorithmes de chiffrement symétriques pour chiffrer et déchiffrer des données.

• 5.3.B.1 Les algorithmes de chiffrement informatiques fonctionnent sur des données binaires. L'algorithme de chiffrement symétrique le plus courant est le Advanced Encryption Standard (AES). Le chiffrement AES est utilisé pour sécuriser les transmissions Wi-Fi, la navigation Internet, le chiffrement de fichiers sur disque et le chiffrement au niveau matériel sur les processeurs.
• 5.3.B.2 AES est un chiffrement par bloc à clé symétrique qui chiffre les données par blocs de 128 bits (16 octets). AES peut fonctionner avec des clés de longueurs variables. Des clés plus longues produisent un chiffrement plus sûr mais nécessitent plus de temps pour chiffrer et déchiffrer.
• 5.3.B.3 Le chiffrement et le déchiffrement symétriques peuvent être effectués via la ligne de commande, des logiciels spécialisés ou des outils en ligne.
  • Sur une interface en ligne de commande, les utilisateurs peuvent chiffrer ou déchiffrer avec OpenSSL.
  • Les logiciels spécialisés comme AES Crypt sont des outils open source capables de chiffrer et de déchiffrer des fichiers.
  • Il existe de nombreux outils en ligne pour chiffrer et déchiffrer des fichiers.
• 5.3.B.4 En utilisant OpenSSL dans une CLI, un utilisateur peut chiffrer et déchiffrer un fichier à l'aide des commandes suivantes (notez que la clé de chiffrement est dérivée du mot de passe fourni) :
  • Pour chiffrer un fichier nommé test avec AES utilisant une clé de 128 bits, utilisez la commande : openssl enc -aes-128-cbc -e -in test -k password -out test.enc
  • Pour déchiffrer le fichier chiffré en utilisant la même clé, utilisez la commande : openssl enc -aes-128-cbc -d -in test.enc -k password -out text

Objectif d'apprentissage 5.4.A : Déterminer la clé asymétrique appropriée à utiliser lors de l'envoi ou de la réception de données chiffrées.

• 5.4.A.1 Le chiffrement asymétrique permet aux utilisateurs de communiquer en toute sécurité sans avoir au préalable organisé une clé secrète partagée.
• 5.4.A.2 Lors de l'utilisation du chiffrement asymétrique, chaque entité recevant des données doit d'abord générer une paire de clés. Les paires de clés sont des chaînes binaires de longueur égale générées simultanément par un processus mathématique. Une clé est désignée comme clé publique et l'autre comme clé privée. Les clés sont des inverses mathématiques l'une de l'autre — chaque clé inverse son partenaire. N'importe quelle clé peut être utilisée pour chiffrer des informations, mais seule l'autre clé de la paire de clés pourra ensuite les déchiffrer.
• 5.4.A.3 Une fois que le récepteur a généré la paire de clés, la clé privée doit être stockée en toute sécurité. Si la clé privée est exposée, partagée, volée, corrompue ou compromise, la paire de clés doit être supprimée et une nouvelle paire de clés doit être générée, car la sécurité de l'algorithme de chiffrement repose sur la sécurité de la clé privée. La clé publique est publiée pour que chacun puisse la voir et l'utiliser.
• 5.4.A.4 Pour envoyer des informations en toute sécurité à quelqu'un, l'expéditeur utilisera la clé publique du récepteur pour chiffrer les données et les envoyer. Seul le récepteur disposant de la clé privée pourra déchiffrer et lire les informations.

Objectif d'apprentissage 5.4.B : Expliquer pourquoi la longueur d'une clé impacte la sécurité des données chiffrées.

• 5.4.B.1 Des clés plus longues entraînent des espaces de clés plus grands. Pour des clés binaires, une clé de longueur n bits a un espace de clés de $2^n$.
• 5.4.B.2 L'utilisation d'une application pour deviner au hasard une clé de chiffrement de longueur n bits signifie qu'en moyenne, un adversaire sera capable de deviner la bonne clé en $2^n \div 2$ (ou $2^{n-1}$) tentatives.
• 5.4.B.3 Bien que les clés plus longues soient plus sûres, elles nécessitent également plus de temps pour chiffrer et déchiffrer les messages.
• 5.4.B.4 La puissance de traitement informatique et l'efficacité continuent de s'améliorer, permettant aux logiciels de deviner les clés plus rapidement. Les recommandations de longueur de clé pour les algorithmes de chiffrement symétriques et asymétriques sont périodiquement augmentées pour tenir compte de l'accroissement de la puissance de traitement.
• 5.4.B.5 La comparaison de la longueur des clés n'est valide que lorsqu'on compare des clés pour le même algorithme de cryptographie.
  • Exemples illustratifs pour 5.4.B.5 :
    • Une clé AES de 256 bits est plus sûre qu'une clé AES de 128 bits.
    • Une clé RSA de 4096 bits est plus sûre qu'une clé RSA de 2048 bits.
    • Les clés RSA et AES ne peuvent pas être directement comparées entre elles pour déterminer le niveau de sécurité.

Objectif d'apprentissage 5.4.C : Appliquer des algorithmes de chiffrement asymétriques pour chiffrer et déchiffrer des données.

• 5.4.C.1 Les algorithmes de chiffrement asymétriques courants incluent RSA et la cryptographie à courbe elliptique (ECC). Les algorithmes asymétriques sont utilisés dans de nombreuses applications, notamment les signatures numériques et les certificats numériques.
• 5.4.C.2 Tout comme pour le chiffrement symétrique, le chiffrement et le déchiffrement asymétriques peuvent être effectués via la ligne de commande, des logiciels spécialisés ou des outils en ligne.
  • Sur une interface en ligne de commande, les utilisateurs peuvent chiffrer ou déchiffrer avec OpenSSL.
  • Les logiciels spécialisés comme RSA Encryption Tool sont des outils open source capables de chiffrer et de déchiffrer des fichiers.
  • Il existe de nombreux outils en ligne pour chiffrer et déchiffrer des fichiers.
• 5.4.C.3 Dans une CLI, un utilisateur peut générer une paire de clés asymétriques et chiffrer ou déchiffrer des fichiers selon les besoins.
  • Pour générer une paire de clés RSA de 2048 bits et sauvegarder la clé dans un fichier nommé rsa.pem, utilisez la commande : openssl genrsa -out rsa.pem 2048
  • Pour extraire la clé publique de rsa.pem vers un fichier nommé public.pem, utilisez la commande : openssl rsa -pubout -in rsa.pem -outform PEM -out public.pem
  • Pour chiffrer le fichier test en utilisant le chiffrement RSA et le fichier de clé public.pem, utilisez la commande : openssl pkeyutl -encrypt -pubin -inkey public.pem -in test -out test.enc
  • Pour déchiffrer le fichier test.enc en utilisant le fichier rsa.pem, exécutez la commande : openssl pkeyutl -decrypt -inkey rsa.pem -in test.enc -out test

Objectif d'apprentissage 5.5.A : Identifier les principes de sécurité applicatifs de « Secure by Design » et de « Security by Default ».

• 5.5.A.1 « Secure by Design » (Sûr dès la conception) est une initiative qui encourage les entreprises à intégrer la sécurité dans toutes les phases du développement de produit, y compris la conception. Lorsque les organisations implémentent « Secure by Design », la sécurité est un principe de conception et non seulement une fonctionnalité technique.
• 5.5.A.2 « Secure by Design » comprend trois principes de conception :
  • i. Les entreprises devraient assumer la responsabilité des résultats en matière de sécurité des clients. Les entreprises devraient concevoir des produits qui répondent aux besoins de sécurité de leurs clients.
  • ii. Les entreprises devraient adopter une transparence et une responsabilisation radicales. Partager rapidement des nouvelles et mises à jour pertinentes liées à la sécurité du produit augmente la sécurité pour tous.
  • iii. Les entreprises devraient construire une structure organisationnelle et un leadership pour mettre en œuvre la sécurité dès la conception. Les entreprises ont besoin de leaders focalisés sur la sécurité et ayant une posture axée sur la sécurité.
• 5.5.A.3 La conception sécurisée comprend le concept de sécurité par défaut, qui consiste à activer les fonctionnalités de sécurité pour les logiciels et les appareils par défaut. Les appareils et logiciels doivent être sécurisés dès leur première utilisation, avec les fonctionnalités de sécurité déjà activées.

Objectif d'apprentissage 5.5.B : Expliquer comment la normalisation des entrées utilisateur protège les applications.

• 5.5.B.1 Lorsqu'un utilisateur saisit des informations dans une application, celle-ci encapsule généralement cette entrée dans des caractères spéciaux pour la traiter. Les caractères qui encadrent l'entrée utilisateur sont appelés caractères de contrôle et inclent l'apostrophe, la guillemet double et le point-virgule.
• 5.5.B.2 Lors de la création d'un programme prenant des entrées utilisateur, les programmateurs doivent utiliser une fonction pour vérifier que l'entrée utilisateur correspond aux critères attendus et ne contient aucun caractère de contrôle susceptible d'être utilisé pour manipuler le système. Cette fonction de vérification peut normaliser l'entrée utilisateur en supprimant les caractères potentiellement malveillants, ou elle peut afficher une erreur à l'utilisateur et forcer celui-ci à fournir une entrée différente. Cela peut protéger contre de nombreuses attaques applicatives, notamment :
  • Attaques d'injection SQL
  • Attaques XSS
  • Attaques de traversal de répertoire

Objectif d'apprentissage 5.6.A : Expliquer comment détecter les attaques sur les données.

• 5.6.A.1 Les appareils suivent et enregistrent quand les données sont accédées et par qui. Le processus consistant à enregistrer et surveiller les activités des utilisateurs est appelé comptabilisation (accounting). L'analyse de ces journaux peut révéler une activité malveillante lorsqu'un adversaire tente d'accéder, copier, déplacer ou supprimer des données. Une activité suspecte peut inclure :
  • Accès à des fichiers non typiquement consultés
  • Accès à des fichiers ou applications en dehors des habitudes normales d'un utilisateur (y compris l'heure de la journée, l'emplacement et le type d'appareil)
  • Tentatives de suppression ou de copie de fichiers sensibles
• 5.6.A.2 Un pot de miel (honeypot) est un fichier qui semble contenir des données précieuses (par ex., des informations de carte de crédit, des PII, des mots de passe), mais les données du fichier sont fausses. Un système peut alerter les défenseurs si quelqu'un tente d'accéder au pot de miel. Puisque le pot de miel est un fichier fictif, il n'y a aucune raison légitime de l'accéder, et toute tentative d'accès serait un indicateur d'activité malveillante.
• 5.6.A.3 Les fonctions de hachage cryptographique peuvent générer un digest pour les données et révéler si les données ont été modifiées. Si un fichier a changé de manière inattendue, cela peut être un signe d'activité malveillante.

Objectif d'apprentissage 5.6.B : Déterminer les contrôles pour détecter les attaques contre les applications ou les données.

• 5.6.B.1 Le coût est un critère dans la détermination des contrôles de détection. Les contrôles de détection comme les pots de miel et l'utilisation de valeurs de hachage pour vérifier l'intégrité des données sont peu coûteux. Certaines organisations investissent dans des services tiers de prévention des pertes de données (DLP), qui surveillent l'accès, l'utilisation et la transmission des données par les utilisateurs à travers l'organisation pour détecter les activités suspectes ; les services DLP offrent de solides capacités de détection à un coût plus élevé.
• 5.6.B.2 La sensibilité ou la criticité des données ou des applications est un critère dans la détermination des contrôles de détection. Les données ou applications plus sensibles ou critiques sont plus susceptibles d'être ciblées par un adversaire et doivent être surveillées plus étroitement.
• 5.6.B.3 La classification des données est un critère dans la détermination des contrôles de détection. Les données classifiées comme privées, éducatives, de santé ou financières ont souvent des exigences légales ou réglementaires en matière de détection et de surveillance.

Objectif d'apprentissage 5.6.C : Évaluer l'impact d'une méthode de détection des attaques contre une application ou des données.

• 5.6.C.1 Pour fonctionner à une vitesse efficace, l'analyse des journaux doit être complétée par une certaine automatisation. Les pots de miel offrent des capacités de détection quasi instantanées.
• 5.6.C.2 Certains outils DLP, pots de miel et analyses de journaux automatisées en temps réel fournissent des alertes alors qu'une attaque se produit. Ces outils permettent une réponse rapide qui peut arrêter une attaque avant qu'elle ne cause davantage de dommages. L'analyse rétrospective des journaux et l'utilisation de hachages cryptographiques pour vérifier l'intégrité des données identifient les attaques après qu'elles se sont produites.
• 5.6.C.3 Des faux négatifs peuvent se produire dans la détection des attaques sur les applications et les données. Les fonctions de hachage cryptographique ne détectent que si les données ont été modifiées. Un adversaire pourrait consulter et voler des données sans les modifier, et une fonction de hachage cryptographique ne détecterait pas cela. Les pots de miel ne peuvent pas détecter les adversaires qui n'essayent pas de les accéder.

Objectif d'apprentissage 5.6.D : Identifier si un fichier a été modifié en vérifiant son hachage.

• 5.6.D.1 Les fonctions de hachage cryptographique peuvent aider à identifier les changements dans un fichier car elles sont reproductibles : la même entrée produit toujours la même sortie pour une fonction de hachage donnée.
• 5.6.D.2 Les hachages peuvent être calculés via la ligne de commande sur un ordinateur, un site web ou un logiciel spécialisé.
  • Dans Windows PowerShell, si un utilisateur voulait générer le hachage SHA256 pour un fichier nommé testfile, il utiliserait la commande : Get-FileHash testfile -Algorithm SHA256
  • Dans BASH, la même chose pourrait être accomplie avec la commande : sha256sum testfile
  • Dans zsh, le terminal de ligne de commande courant sur les ordinateurs Apple, cela pourrait être accompli avec la commande : shasum -a 256 testfile
• 5.6.D.3 Un fichier peut être haché et sa sortie de hachage enregistrée. Ensuite, il peut être haché à nouveau plus tard, et la deuxième sortie de hachage peut être comparée à la sortie de hachage précédente pour le même fichier. Si le hachage d'un fichier change, alors le fichier a été modifié entre la génération du premier et du second hachage.

Objectif d'apprentissage 5.6.E : Appliquer des techniques de détection pour identifier et rapporter les indicateurs d'attaques applicatives en analysant les fichiers journaux.

• 5.6.E.1 Les attaques d'injection SQL peuvent être détectées en examinant les journaux d'application et de serveur concernant les entrées utilisateur à la recherche de mots-clés et symboles de contrôle SQL tels que :
  • Un simple (') ou un double (") caractère guillemet
  • Conditions booléennes comme OR 1=1
  • Un double tiret (qui indique un commentaire dans SQL) : --
  • Mots-clés de contrôle SQL (toujours en majuscules) comme WHERE, IN, FROM
• 5.6.E.2 Les attaques XSS peuvent être détectées en examinant les entrées utilisateur à la recherche de balises suspectes, en particulier la balise .
• 5.6.E.3 Pour les applications web, les débordements de tampon peuvent être détectés en vérifiant la quantité de données que l'utilisateur envoie à l'application web dans sa requête. Les champs couramment vérifiés sont la longueur de l'URL, la longueur des cookies, la longueur de la chaîne de requête et la longueur totale de la requête. De longues chaînes dans l'un de ces champs peuvent être un indicateur d'une tentative d'attaque par débordement de tampon.
• 5.6.E.4 Les attaques de traversal de répertoire peuvent être détectées en examinant les journaux d'application et de serveur. Les requêtes HTTP GET qui incluent des chemins avec des séquences de ../ sont des indicateurs d'un adversaire tentant un traversal de répertoire.