Pourquoi la cybersécurité est-elle importante ?

En 2023, le coût moyen d'une violation de données était de 4,45 millions de dollars à l'échelle mondiale, ce qui, en seulement trois ans, représentait une augmentation de 15 % par rapport à 2020.12 Ces coûts couvrent les dépenses engagées pour découvrir et répondre aux violations, les pertes de revenus dues aux temps d'arrêt, et les dommages à long terme à la réputation et à la marque de l'entreprise. Cybersecurity Ventures a récemment partagé ses dix principales prévisions et statistiques en matière de cybersécurité pour 2024, révélant le fait alarmant que les dommages financiers mondiaux liés à la cybercriminalité atteindront probablement 10,5 billions de dollars d'ici 2025. Sur la base de ce total, si la cybersécurité était considérée comme un pays, elle se classerait au troisième rang, derrière les États-Unis et la Chine, comme la plus grande économie mondiale.13 Les informations personnelles identifiables sont généralement la cible des cybercriminels. Ils collectent des informations, telles que les noms, adresses, numéros d'identification et informations de carte de crédit, et les vendent sur le dark web ou d'autres marchés souterrains. Cela entraîne plusieurs conséquences pour ces organisations, notamment des amendes réglementaires, des actions en justice et la perte de confiance des clients.

La cybersécurité est de plus en plus importante à mesure que le coût des violations augmente. Cependant, une stratégie de cybersécurité complète basée sur les meilleures pratiques et utilisant l'apprentissage automatique, l'analytique avancée et l'intelligence artificielle peut combattre efficacement les cybermenaces et réduire les impacts des violations.

Domaines de la cybersécurité et techniques cryptographiques associées

La cybersécurité comprend divers domaines qui constituent la cybersécurité globale. Les domaines courants de la cybersécurité incluent les suivants :

• Protection des systèmes informatiques et des réseaux qui assurent la sécurité à l'échelle nationale, la santé économique et la sécurité publique, appelée sécurité de l'infrastructure (infrastructure security). Le cadre de cybersécurité du National Institute of Standards and Technology (NIST) est destiné à aider les organisations dans ce domaine. Des directives supplémentaires sont fournies par le U.S. Department of Homeland Security.
• Protection des réseaux informatiques câblés et sans fil contre les intrusions, appelée sécurité des réseaux (network security). Les conceptions des systèmes d'exploitation, des machines virtuelles et des moniteurs doivent inclure des protections contre l'utilisation non autorisée.
• Protection des applications sur site et dans le nuage, avec une sécurité intégrée dès la phase de conception pour la gestion des données et l'authentification des utilisateurs, appelée sécurité des applications (application security). Le processus d'authentification confirme l'identité et l'autorisation des personnes et des appareils qui utilisent un système. De nombreuses ressources soutiennent ces efforts, y compris des livres et des documents en ligne sur l'ingénierie de la sécurité, la programmation « robuste » et la programmation sécurisée pour des systèmes d'exploitation spécifiques.
• Protection des données, des fichiers numériques et des autres informations qu'un système maintient, appelée sécurité de l'information (information security). Par exemple, les systèmes de bases de données doivent se protéger contre l'injection SQL en veillant à ce que les requêtes émises vers la base de données ne contiennent pas de code malveillant susceptible de compromettre la sécurité de la base de données et de son infrastructure. La sécurité de l'information nécessite des mesures de protection des données, telles que le Règlement général sur la protection des données (GDPR), qui sécurisent les données sensibles contre l'accès, l'exposition ou le vol non autorisés.

Ces domaines fonctionnent en coopération pour créer un plan de gestion des risques de cybersécurité (Figure 14.7).

Figure 14.7 La cybersécurité doit être basée sur un plan complet de gestion des risques qui identifie et évalue les risques de cybersécurité, conçoit et met en œuvre des pratiques pour atténuer ces risques, et surveille le système et identifie les domaines qui doivent être mis à jour. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Un pilier important de l'assurance cybersécurité (cybersecurity assurance) est la non-répudiation (nonrepudiation), qui fournit la preuve de l'origine, de l'authenticité et de l'intégrité des données. La non-répudiation est obtenue par la cryptographie (cryptography) en utilisant, par exemple, des signatures numériques, qui sont utilisées dans les transactions en ligne pour garantir qu'une partie ne peut pas ultérieurement nier avoir passé une commande ou nier l'authenticité de sa signature. En plus des signatures numériques, la non-répudiation est également utilisée dans les contrats numériques et les courriels. La non-répudiation des courriels implique des méthodes telles que le suivi des courriels pour assurer aux expéditeurs que les messages sont livrés et fournit également aux destinataires une preuve de l'identité de l'expéditeur. Cela garantit qu'aucune partie ne peut nier qu'un message a été envoyé, reçu et traité.

Au-delà de la simple sécurisation des systèmes d'information, la cybersécurité exige la création et la gouvernance de processus qui protègent les organisations et les individus contre les violations coûteuses. L'éducation des utilisateurs finaux est une partie essentielle de ce processus. Les organisations doivent promouvoir la sensibilisation à la sécurité pour améliorer la sécurité des points d'extrémité. Par exemple, former les utilisateurs à supprimer les pièces jointes suspectes et à éviter d'utiliser des périphériques USB inconnus peut aider.

La reprise après sinistre et la planification de la continuité des activités sont également essentielles pour minimiser les perturbations des opérations clés. Cela nécessite des outils et des procédures pour répondre aux incidents de cybersécurité, aux catastrophes naturelles et aux pannes de courant. Le stockage des données est un autre domaine critique. Les mesures de protection qui favorisent la résilience des données avec des garanties incluent le chiffrement et des copies de données immuables et isolées qui peuvent être rapidement restaurées pour récupérer les données et minimiser l'impact d'une cyberattaque.

L'évolutivité (evolvability) est une qualité cybernétique importante, mais l'évolution des plateformes sur lesquelles les systèmes d'information peuvent être déployés crée un besoin de nouvelles mesures de sécurité. Par exemple, la sécurité des solutions mobiles nécessite des mesures de protection spécifiques pour protéger les applications, les conteneurs (containers) et le courrier mobile. De plus, lors de l'utilisation du nuage, les organisations doivent assurer un calcul confidentiel en chiffrant les données au repos (c'est-à-dire pendant que les données sont stockées dans le nuage), pendant le transfert et pendant le traitement. Cela garantit que les processus répondent aux exigences commerciales et aux normes de conformité réglementaire et soutient la confidentialité (privacy) des clients.

Idées fausses sur la cybersécurité

En raison de l'évolution constante de la technologie, il existe également plusieurs idées fausses concernant les risques de cybersécurité.

1. Les menaces ne viennent que de l'extérieur de l'organisation. Au lieu de cela, les violations peuvent impliquer des personnes au sein de l'organisation travaillant de manière malveillante avec des pirates externes ou des groupes organisés.
2. Les risques sont connus et peuvent être prédits. En réalité, la surface d'attaque s'étend constamment avec de nouvelles vulnérabilités, et l'erreur humaine de la part d'employés ou de sous-traitants négligents peut également augmenter le risque de violations de données.
3. Les vecteurs d'attaque sont limités. Les cybercriminels découvrent constamment de nouveaux vecteurs d'attaque à travers divers environnements.
4. L'industrie est sûre. Chaque industrie est confrontée à des risques de cybersécurité, et les adversaires exploitent les réseaux de communication des gouvernements et du secteur privé. Les attaques par rançongiciel (ransomware) s'étendent aux organisations à but non lucratif et aux gouvernements locaux, et les menaces augmentent dans d'autres domaines.14

Chaîne d'approvisionnement et problèmes de sécurité

Après la pandémie de COVID-19, les entreprises ont toujours du mal à obtenir les biens et services nécessaires. De nombreux produits sont toujours dans les ports et les entrepôts en attente de livraison car il n'y a pas assez de chauffeurs de camion dans la main-d'œuvre. À la suite de la pénurie d'usines de fabrication de puces, l'industrie automobile a commencé à se redresser en 2023. Pendant de nombreux mois, les lots des concessionnaires automobiles étaient vides de nouvelles voitures. Il y a une pression constante sur les travailleurs pour acheminer les biens et les matériaux aux clients plus rapidement. Amazon a établi un précédent pour le taux de livraison des marchandises que le reste du monde a du mal à suivre.

Le monde a connu une augmentation des cybermenaces car de plus en plus d'activités commerciales sont menées en ligne. Si vous allez dans un stade sportif ou un événement de concert, la plupart d'entre eux impliquent des transactions sans espèces. Toutes les transactions doivent être effectuées avec des cartes de crédit ou de débit. Cela signifie qu'il y a beaucoup plus de chances que vos informations soient divulguées en raison du nombre d'entreprises avec lesquelles vous interagissez. Certes, c'est votre choix d'utiliser ces entreprises, mais rappelez-vous, la sécurité n'est aussi forte que son maillon le plus faible. À mesure que notre culture exige des transactions sans espèces, le nombre de surfaces d'attaque disponibles pour les pirates augmente. Si nous mettons en œuvre les concepts de supersociétés (supersocieties) et nous nous immergeons dans cette technologie, alors si une vulnérabilité de sécurité nous compromet, cela pourrait causer un préjudice irréparable à notre mode de vie.

Technologies clés et meilleures pratiques en cybersécurité

Les technologies clés de cybersécurité et les meilleures pratiques associées se répartissent généralement en trois catégories : la gestion des identités et des accès (identity and access management), une plateforme de sécurité des données et la gestion des informations et des événements de sécurité.

La technologie utilisée pour gérer les rôles et les privilèges d'accès des utilisateurs est la gestion des identités et des accès (IAM) (identity and access management (IAM)). Les approches utilisées pour autoriser l'accès aux systèmes incluent l'authentification unique, l'authentification multifacteur, les comptes d'utilisateurs privilégiés et la gestion du cycle de vie des utilisateurs. Le SSO empêche les utilisateurs de saisir leurs identifiants plusieurs fois au cours de la même session. L'authentification multifacteur exploite plusieurs identifiants d'accès fournis via différents appareils. Les comptes d'utilisateurs privilégiés ne sont accessibles qu'à des utilisateurs spécifiques. La gestion du cycle de vie des utilisateurs gère les identifiants des utilisateurs, de l'enregistrement initial à la désactivation. Les professionnels de la cybersécurité utilisent les outils IAM pour enquêter et répondre aux problèmes de sécurité à distance et contenir les dommages causés par les violations.

Une plateforme de sécurité des données (data security platform) est conçue pour automatiser la protection proactive des informations en surveillant et en détectant les vulnérabilités et les risques liés aux données dans plusieurs environnements, y compris les plateformes hybrides et multinuages. La protection fournie par une plateforme de sécurité des données simplifie la conformité aux réglementations en matière de confidentialité (privacy) des données et prend en charge les sauvegardes et le chiffrement pour assurer la sécurité des données.

La pratique de la gestion des informations et des événements de sécurité (SIEM) (security information and event management (SIEM)) se concentre de manière proactive sur la détection et la correction automatisées des activités suspectes des utilisateurs, basées sur l'analyse des événements de sécurité. Les solutions SIEM analysent généralement le comportement des utilisateurs et utilisent des techniques d'intelligence artificielle pour détecter et corriger les activités suspectes conformément aux directives de gestion des risques de l'organisation. Les outils SIEM peuvent être intégrés à des plateformes d'orchestration, d'automatisation et de réponse en matière de sécurité conçues pour automatiser entièrement la gestion des incidents de cybersécurité sans intervention humaine.

Certaines organisations choisissent également d'utiliser une stratégie de confiance zéro, qui suppose que le système est compromis et met en place des contrôles pour valider en permanence chaque utilisateur, appareil et connexion dans le système en termes d'authenticité et de finalité.

Authentification et mots de passe

L'authentification (authentication) confirme l'identité et l'autorisation des personnes et des appareils qui utilisent un système. C'est un processus vital en deux étapes pour garantir que seuls les utilisateurs autorisés ont accès à un système. L'authentification nécessite d'abord une identification suivie d'une vérification pour établir et confirmer les identifiants uniques d'un utilisateur et s'assurer que l'utilisateur est autorisé.

Un mot de passe (password) est une chaîne secrète de caractères utilisée pour accéder à un système. C'est un élément essentiel de l'authentification. Pour fonctionner comme un outil de cybersécurité, les mots de passe doivent être sécurisés, ce qui peut être difficile. Les attaquants peuvent voler des mots de passe en les devinant, en installant un enregistreur de frappe matériel ou logiciel, en trouvant des mots de passe écrits, en les obtenant via l'ingénierie sociale/hameçonnage, en interceptant le mot de passe sur le réseau, ou en les volant à un service ou à un tiers.

Pour faire face à ces cybermenaces, la Cybersecurity and Infrastructure Security Agency du DHS propose trois conseils pour les mots de passe :15

• Créez des mots de passe longs d'au moins 16 caractères.
• Rendez les mots de passe aléatoires en suivant les règles de mot de passe recommandées par le NIST.
• Assurez-vous que les mots de passe sont uniques en utilisant un mot de passe différent pour chaque point d'accès dans un système.

Contrôle d'accès

Une partie vitale de la cybersécurité est le contrôle d'accès (access control), qui régule les personnes et les appareils pouvant utiliser les ressources d'un système informatique. Les trois conceptions de contrôle d'accès les plus courantes incluent les suivantes :

• Le contrôle d'accès obligatoire est un système strict où les décisions de sécurité sont entièrement contrôlées par un administrateur de politique central, rendant impossible pour les utilisateurs de définir des permissions indépendamment de la propriété.
• Le contrôle d'accès discrétionnaire est un système où les utilisateurs peuvent définir des permissions pour leurs fichiers, y compris accorder des droits d'accès à d'autres utilisateurs sur le même système. Le DAC est l'approche de conception de contrôle d'accès la plus courante dans les systèmes d'exploitation commerciaux. Bien que généralement moins sécurisé que le contrôle obligatoire, le DAC est plus facile à implémenter et plus flexible.
• Le contrôle d'accès basé sur les rôles (RBAC) est un système dans lequel l'accès dépend du rôle d'un individu ou d'un groupe dans une organisation et de l'accès dont ils ont besoin pour répondre aux exigences du poste. Généralement, les rôles avec plus de responsabilités et d'autorité ont un accès plus important au système.

Les attaques typiques lancées contre la cryptographie impliquent généralement les suivantes :

• force brute (par exemple, essayer toutes les clés privées possibles)
• attaques mathématiques
• attaques temporelles (par exemple, basées sur la connaissance du temps nécessaire pour déchiffrer)
• attaque par faute matérielle (par exemple, profiter d'un matériel défectueux pour générer des signatures numériques)
• attaque par texte chiffré choisi (par exemple, recueillir des informations en obtenant les déchiffrements de textes chiffrés choisis et tenter de récupérer à partir de ces informations la clé secrète utilisée pour le déchiffrement)
• modifications architecturales (par exemple, utiliser la connaissance des vulnérabilités)

Anonymat et confidentialité

La protection de l'anonymat et de la confidentialité (privacy) est un aspect important de la cybersécurité. Pouvoir interagir sur Internet, même publiquement, tout en dissimulant son identité, est considéré comme de l'anonymat (anonymity). L'anonymat n'est pas la même chose que le secret/la confidentialité. Comme discuté précédemment, la confidentialité concerne le contenu des messages (c'est-à-dire ce qui a été dit). L'anonymat concerne les identités (c'est-à-dire qui l'a dit et à qui) et doit être préservé pour garantir certaines libertés civiles telles que l'autonomie, la libre association, la liberté d'expression et la liberté de censure et de surveillance.

Il existe un large éventail de « nimité », y compris :

• anonymat liant (par exemple, cartes de fidélité, téléphone mobile prépayé),
• ,
• anonymat non liant (par exemple, paiement en espèces), et
• vérinimité (par exemple, numéros de carte de crédit, permis de conduire, adresses).

En restant anonymes, les utilisateurs rendent difficile pour les pirates de voler leurs données personnelles (par exemple, mots de passe, informations de carte de crédit). Cela permet également aux utilisateurs de préserver leurs libertés civiles (par exemple, liberté d'expression et d'association) sur les médias sociaux. L'anonymat peut également être important pour les personnes soucieuses de leur sécurité et qui ne veulent pas créer de risques de sécurité en raison de leurs activités en ligne.

Garder vos actions en ligne, telles que les messages destinés uniquement à certaines personnes, cachées du public est appelé confidentialité (privacy). La confidentialité est considérée comme un droit humain fondamental. Bien que non explicite dans la Constitution américaine, les droits à la confidentialité sont implicites par les protections personnelles offertes dans les premier, troisième, quatrième, cinquième et neuvième amendements de la Déclaration des droits. Comme le montre la Figure 14.9, la confidentialité est liée à l'anonymat mais est un concept distinct. L'anonymat et la confidentialité sont importants pour promouvoir la cybersécurité.

Figure 14.9 La confidentialité et l'anonymat sont des concepts liés qui sont importants pour promouvoir la cybersécurité. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

L'anonymat sur Internet est difficile, voire impossible, à atteindre pour les utilisateurs moyens, mais il semble facile pour les personnes peu scrupuleuses. L'anonymat est une technique de pointe qui repose sur des intermédiaires proxy qui relaient le trafic Internet via des tiers de confiance. Généralement, le processus nécessite la mise en place d'un réseau privé virtuel (VPN) chiffré vers le site du tiers, et tout votre trafic passe par celui-ci.

Pour comprendre comment les personnes peu scrupuleuses utilisent les proxys, supposons un scénario décrit dans la Figure 14.10 où Alice veut envoyer un message M à Bob. Bob ne sait pas que le message M vient d'Alice, et Eve (« Eve » est l'abréviation de eavesdropper, c'est-à-dire « espion ») ne peut pas déterminer qu'Alice communique avec Bob. HMA accepte les messages chiffrés pour lui, puis extrait les adresses de destination correspondantes et transmet le message en conséquence.

Figure 14.10 Quand Alice envoie un message à Bob, HMA accepte les messages chiffrés, puis extrait les adresses de destination correspondantes et transmet les messages en conséquence. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

L'anonymat (anonymity) est destiné à contrer le type de surveillance imposé par le Patriot Act (section 215, et les lettres de sécurité nationale ou NSL) et le FISA Amendment Act.

Un ancien rapport de transparence de Google (Tableau 14.4) montre le nombre de NSL que les agents du FBI ont émises sans l'approbation d'un juge pour obtenir des informations personnelles.

Les NSL couvrent tout sauf le contenu de vos communications (c'est-à-dire si, quand, combien, qui). Ces données sont incluses dans l'exception car ces métadonnées fournissent souvent des informations privilégiées qui sont essentiellement, selon la FTC, un « proxy pour le contenu ». En fait, la collecte de données d'appels en vrac par la National Security Agency des États-Unis a été jugée illégale en 2015.

Des outils de chiffrement tels que Pretty Good Privacy, introduit précédemment, peuvent être utilisés. GnuPG est une recréation logicielle libre de PGP créée par Phil Zimmerman (1991). Ces outils permettent aux utilisateurs de chiffrer les courriels pour en masquer le contenu en créant un hachage du contenu du courriel et en utilisant des signatures numériques pour signer le hachage. Le texte du message et la signature numérique attachée au message sont tous deux protégés à l'aide d'un chiffrement hybride. Les signatures numériques nécessitent une cryptographie à clé publique (qui a des clés publiques et privées distinctes). Avant d'envoyer un message, le message est signé avec la clé de signature, et le message et sa signature sont chiffrés avec la clé de chiffrement publique du destinataire. Une fois le message reçu, il est déchiffré avec la clé privée pour l'extraire et sa signature. La clé de vérification publique de l'expéditeur est ensuite utilisée pour vérifier l'authenticité de la signature.

Les empreintes digitales doivent être utilisées pour sécuriser davantage ce processus. Étant donné que la clé publique de Bob peut être obtenue à partir de son site web, elle doit être vérifiée via une communication hors bande des empreintes digitales. Une empreinte digitale est un hachage cryptographique d'une clé. Pour prendre en charge cette approche, vous avez besoin de serveurs de clés qui stockent les clés publiques pour rechercher les clés par nom/adresse électronique et les vérifier avec des empreintes digitales. Si vous ne connaissez pas Bob personnellement, vous pouvez vous fier au Web of Trust ou au mécanisme « ami d'un ami » (c'est-à-dire que Bob présente Alice à Caro en signant la clé d'Alice).

L'utilisation du chiffrement présente des inconvénients car la clé privée de Bob peut être compromise. Dans ce cas, les spécificités des clés peuvent être connues, et les messages passés peuvent être déchiffrés et lus. Étant donné que la signature de l'expéditeur est disponible dans les messages envoyés, il devient également possible de prouver l'identité de l'expéditeur, ce qui compromet le système de sécurité. Cette attaque expose de nombreux enregistrements incriminants, y compris le matériel de clé qui déchiffre les données envoyées sur l'Internet public et les signatures avec des preuves de qui a dit quoi.

Il n'y a rien de mieux que des conversations « hors dossier » où Alice et Bob parlent dans une pièce, et personne d'autre ne peut les entendre. Dans ce cas, personne d'autre ne sait ce qu'ils disent à moins qu'Alice ou Bob ne le leur dise. De plus, personne ne peut prouver ce qui a été dit, ni Alice ni Bob. Sur cette base, les propriétés de communication souhaitables sont les suivantes :

• La déniabilité rend plausible le fait de nier avoir envoyé un message.
• Le secret de transmission permet de protéger les messages passés même si le matériel de clé est compromis.
• Imiter les conversations hors dossier pour faciliter l'authentification déniable. Rendre possible d'être sûr de la personne à qui vous parlez mais incapable de prouver à un tiers ce qui a été dit.

Une technique consiste à utiliser la messagerie hors dossier.

1. Utiliser le protocole Diffie-Hellman authentifié pour établir une clé de session (de courte durée) :
   Diffie-Hellman est un algorithme de sécurité avec une seule clé privée (symétrique) partagée par les deux participants. Alice et Bob conviennent de valeurs pour le nombre premier p et un nombre générateur g, où 1< g < p et g est un nombre quelconque convenu par les deux parties qui est un générateur de p. Le nombre g est un générateur de p car, lorsqu'il est élevé à des puissances entières positives inférieures à p, il ne produit jamais le même résultat pour deux de ces nombres entiers. Pour faciliter le calcul, g est généralement choisi petit, et l'ordre de g doit être premier et approximativement p/2. Alice et Bob choisissent respectivement des valeurs privées x et y et génèrent une clé qu'ils échangent publiquement. Ainsi, Alice sélectionne x et génère la clé publique a = gx modulo p et Bob sélectionne y et génère la clé publique b = gy modulo p. Par exemple, si p = 23 et g = 9, les clés privées pour Alice et Bob sont respectivement 4 et 3, et les clés secrètes pour Alice et Bob sont toutes deux 9.
   Pendant l'échange de clés DH (signé), les seules informations exposées au public (et susceptibles d'être interceptées par des acteurs malveillants) sont x, y, p et g. Aucune d'entre elles n'est suffisante pour récupérer les clés privées d'Alice et Bob. Ce n'est pas non plus une information suffisante pour récupérer la clé cryptographique secrète (symétrique) partagée. SS peut ensuite être utilisée par Alice et Bob pour s'envoyer des messages chiffrés en toute sécurité, ce qui est fait en utilisant un algorithme de chiffrement à clé secrète, en utilisant un hachage de SS comme clé de chiffrement EK, pour transmettre le texte chiffré.
   La force du schéma vient du fait que (gy)x modulo p = (gx)y modulo p est une fonction à sens unique qui prend un temps extrêmement long à calculer/inverser en utilisant tout algorithme connu (juste à partir de la connaissance de p, g, gx modulo p et gy modulo p.
   

   

   (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)
2. Ensuite, Alice utilise le chiffrement à clé secrète sur le message M et l'envoie sous forme de EEK(M) ... et authentifie le message à l'aide d'un code d'authentification de message MACMK(EEK(M), où MK est calculé comme un hachage de l'EK, H :
   

   

   (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)
3. Le renouvellement de clé est effectué à l'aide du protocole DH pour échanger de nouvelles valeurs privées x′ et y′ :
   

   

   (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)
4. Publication de l'ancien MK :
   

   

   (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Notez que l'OTR est plus applicable à la communication interactive qu'au courrier électronique. Il offre l'authentification des messages, la confidentialité, la déniabilité et le secret de transmission. Cependant, il n'existe pas d'exemples pratiques de « déniabilité ». L'OTR est intégré à Adium et Pidgin ; dans ce cas, certaines valeurs par défaut s'appliquent. En particulier, la journalisation est activée par défaut, et l'étiquette dicte de la désactiver, tout comme les cas passés où les activités de personnes ont été découvertes à l'aide de ces journaux (par exemple, Chelsea Manning, qui a divulgué des informations classifiées, a été découverte après que l'armée a examiné les journaux d'accès). C'est très différent de la fonctionnalité OTR de Google Hangout, qui ne permet pas la journalisation de la conversation.

Une solution intéressante d'anonymat est le protocole derrière l'application Signal, qui utilise l'algorithme à double cliquet mis au point par Trevor Perrin et Moxie Marlinspike. Il offre le secret de transmission (c'est-à-dire que les messages d'aujourd'hui sont secrets, même si la clé est compromise demain), le secret futur (c'est-à-dire que les messages de demain sont secrets, même si la clé est compromise aujourd'hui), la déniabilité (aucune preuve permanente/transférable de ce qui a été dit) et l'utilisabilité (c'est-à-dire qu'il tolère la livraison de messages désordonnés).

Une autre idée intéressante pour l'anonymat est le stockage plausiblement déniable. Dans ce cas, l'objectif est de chiffrer les données stockées sur votre disque dur. Quelqu'un peut être contraint de les déchiffrer. L'idée est d'avoir un volume « leurre » avec des informations bénignes.

Notez qu'il peut être utile de différencier l'anonymat de l'expéditeur de celui du destinataire. Un exemple intéressant de protocole qui réalise l'anonymat de l'expéditeur est décrit par David Chaum comme le « problème des cryptographes dînants ».16 Dans ce cas, trois cryptographes dînant ensemble apprennent que le paiement sera effectué anonymement par l'un d'entre eux ou par l'agence qui les emploie. Comme ils respectent le droit de chacun de faire un paiement anonyme mais se demandent si leur agence paiera, ils exécutent le protocole décrit pour réaliser l'anonymat de l'expéditeur.

Une solution naïve pour l'anonymat de la navigation consiste à utiliser des VPN. Les organisations qui les fournissent peuvent recevoir des ordonnances judiciaires demandant des informations relatives à un compte, et elles coopéreront avec les forces de l'ordre si elles reçoivent une ordonnance judiciaire. Une meilleure approche consiste à utiliser Tor en téléchargeant le pack de navigateur Tor ou en devenant bénévole dans le réseau Tor. Tor est basé sur une version modifiée de Firefox et est un système de communication anonyme à faible latence qui masque les métadonnées (c'est-à-dire qui communique). Comme indiqué précédemment, vous pourriez avoir des problèmes si un message chiffré que vous envoyez est intercepté et que les métadonnées incluses sont exposées. Pour éviter cela, Tor masque complètement l'existence de la communication. Tor fonctionne au niveau de la couche transport et permet d'établir des connexions TCP sans révéler votre adresse IP. Le réseau Tor s'appuie sur de nombreux nœuds (c'est-à-dire des routeurs oignon) exploités par des bénévoles et situés dans le monde entier. L'approche Tor devient utile si Alice veut se connecter à un serveur web sans révéler son adresse IP. En termes simples, le routage en oignon (Figure 14.11) se généralise à un nombre arbitraire d'intermédiaires (« mixes » ou « mix-nets »). Alice veut finalement parler à Bob, avec l'aide de HMA, Dan et Charlie, et tant que l'un des mixes est honnête, personne ne peut relier Alice à Bob.

Figure 14.11 Les utilisateurs peuvent atteindre l'anonymat en utilisant Tor. C'est ce qu'utilise le service d'anonymat Tor de qualité industrielle. Il fournit également une communication bidirectionnelle. Le concept clé ici est que personne ne vous connaît vraiment, vous et la destination. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Les chemins de bout en bout de Tor sont appelés Circuits, et Tor utilise presque toujours des circuits à 3 sauts (c'est-à-dire k = 3). Tor équilibre l'anonymat (c'est-à-dire k pas trop petit pour être traçable) et la latence (c'est-à-dire k pas trop grand). Le dernier nœud d'un circuit Tor est appelé un nœud « de sortie ». Pour le monde extérieur, le nœud de sortie Tor initie des connexions vers des destinations. Chaque pair du réseau Tor décide s'il doit être un nœud de sortie ou simplement relayer entre d'autres nœuds Tor. Les nœuds de sortie Tor déterminent également quelles adresses IP/sites web quitter. Les clients Tor apprennent l'existence d'autres pairs Tor en téléchargeant une liste de ceux-ci.17 La liste fournit des informations pour chacun des routeurs Tor, telles que l'adresse IP et le nom d'hôte, le pays où il réside, le temps de fonctionnement, le débit moyen, les sites web pour lesquels il est prêt à être un nœud de sortie, et la clé publique du nœud.

Le modèle d'attaque de Tor est plus « détendu » que les modèles utilisés par les mix-nets typiques. En particulier, Tor ne suppose pas un attaquant passif global. Il suppose qu'un sous-ensemble limité des nœuds Tor est malveillant et qu'il peut y avoir un certain niveau d'écoute sur de petites portions des liens mais pas une vue globale de tout le trafic. Ce modèle d'attaque détendu, qui suppose un adversaire moins puissant, permet à Tor d'atteindre de meilleures performances. Cela dit, il y a quelques aspects que Tor ne couvre pas par rapport aux mix-nets typiques : Tor ne met pas en lot ni ne retarde les paquets. Si un seul client devait communiquer via Tor, il n'y aurait pas d'anonymat. La philosophie derrière le modèle d'attaque détendu de Tor est de supposer que si la performance est suffisamment raisonnable, les utilisateurs seront plus susceptibles de l'adopter. Plus il y aura d'utilisateurs qui l'adopteront, plus il y aura de « trafic de couverture », ce qui rendra plus difficile pour un attaquant de mapper les paquets à un expéditeur. La Figure 14.12 résume le fonctionnement de Tor à un niveau élevé.

Figure 14.12 Tor est un processus en plusieurs étapes qui permet aux utilisateurs d'atteindre l'anonymat en ligne. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; icône de clé de crédit : modification de « Accessible » par Phạm Thanh Lộc/Wikimedia Commons, CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Tor implémente le protocole de confiance suivant :

• Le nœud d'entrée sait qu'Alice utilise Tor, et connaît également l'identité du nœud intermédiaire mais ne connaît pas l'identité de la destination.
• Le nœud de sortie sait qu'un utilisateur Tor se connecte à la destination mais ne sait pas quel utilisateur.
• La destination sait qu'un utilisateur Tor s'y connecte via le nœud de sortie.

Il convient de noter que Tor ne fournit pas de chiffrement entre le nœud de sortie et la destination. Nous avons discuté précédemment de la manière dont les expéditeurs peuvent masquer leur identité. De même, Tor est également un moyen de permettre aux destinations de masquer leur identité. Un exemple était The Silk Road, une boutique en ligne de type eBay où les utilisateurs pouvaient acheter des biens illicites et illégaux et les payer en Bitcoins. L'exploitation d'un tel site web nécessite un certain degré d'anonymat. Par conséquent, il était exploité comme ce que l'on appelle un « service caché Tor ». Les services cachés ont depuis été renommés services oignon.18 Il est intéressant de noter que les services oignon peuvent atteindre l'anonymat du destinataire en utilisant des techniques qui permettent l'anonymat de l'expéditeur (Figure 14.13).19

Figure 14.13 Les services cachés Tor, également connus sous le nom de services oignon, atteignent l'anonymat du destinataire en utilisant des techniques qui permettent l'anonymat de l'expéditeur. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Notez qu'il existe diverses attaques connues contre le routage en oignon et d'autres problèmes comme suit :

• Attaques :
  • Cryptanalyse par tuyau en caoutchouc des opérateurs de mix ; en défense, utilisez des serveurs de mix dans différents pays.
  • L'adversaire opère tous les mixes ; en défense, dispose de nombreux serveurs de mix.
  • L'adversaire observe quand Alice envoie et quand Bob reçoit et relie les deux.
  • L'attaque par canal auxiliaire exploite les informations de synchronisation ; en défense, remplissez les messages ou introduisez des retards significatifs. (Tor fait le premier, mais notez que ce n'est pas suffisant pour la défense.)
• Les problèmes incluent :
  • une performance altérée (c'est-à-dire que les messages peuvent rebondir beaucoup) et
  • une fuite de trafic (supposons que tout votre trafic HTTP/HTTPS passe par Tor, mais pas le reste de votre trafic).

Concernant le problème de la fuite de trafic, la solution de Tor consiste à inspecter les journaux de leur serveur DNS pour voir qui a recherché sensitive.com juste avant l'arrivée de votre connexion à leur serveur web. Le problème général difficile est que l'anonymat est souvent menacé lorsqu'un adversaire peut corréler des sources d'informations distinctes.

Pour résumer, Tor masque les métadonnées (c'est-à-dire le « quoi », ou le contenu du message) via TLS/PGP/OTR/Signal, et masque également le « qui » via le protocole de routage en oignon. Il fournit également un système de messagerie appelé Pond (Figure 14.14), qui masque les parties « quand » et « combien » comme illustré. Notez que Pond n'est pas un courriel ; il s'agit plutôt d'un système de messagerie asynchrone, sécurisé et à confidentialité persistante. Pond cherche à protéger la possibilité de fuite d'informations de trafic contre tout adversaire passif global (c'est-à-dire une confidentialité persistante, pas de spam autorisé, et les messages expirent automatiquement après une semaine).

Figure 14.14 Pond est un système de messagerie asynchrone, sécurisé et à confidentialité persistante qui cherche à protéger contre la fuite d'informations de trafic. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Preuves à divulgation nulle de connaissance

Une preuve à divulgation nulle de connaissance (ZKP) (zero-knowledge proof (ZKP)) est un système cryptographique qui fonctionne comme un outil utile pour protéger la confidentialité (privacy). Avec les ZKP, les utilisateurs s'appuient sur des algorithmes cryptographiques pour vérifier les informations sans accéder aux données sous-jacentes. Les signatures numériques basées sur l'ICP (c'est-à-dire l'algorithme RSA ou ECC) sont des exemples de preuves à divulgation nulle de connaissance. Dans ces cas, la personne détenant la clé privée peut convaincre tout détenteur de clé publique qu'elle connaît la clé privée sans la révéler.

Les propriétés des ZKP incluent :

• Complétude : Une affirmation est vraie si un prouveur honnête peut convaincre un vérificateur honnête.
• Solidité : Si le prouveur est malhonnête, il ne peut pas tromper le vérificateur.
• Divulgation nulle de connaissance : Aucune information privée n'est révélée au vérificateur.

Pour comprendre les ZKP, il est important de connaître le théorème PCP, qui stipule que tout problème de décision dans la classe de complexité NP possède des preuves vérifiables de manière probabiliste de complexité de requête constante et de complexité de hasard logarithmique.

Pour une probabilité d'erreur de 2-k, 3k positions de bits doivent être vérifiées. (Par exemple, la probabilité d'erreur de solidité de 2-40 ≈ 10-12 avec une vérification de 120 bits.)

Les preuves d'intégrité computationnelle sont des systèmes de preuve probabilistes basés sur le théorème PCP, permettant à un prouveur de convaincre un vérificateur de l'exactitude d'un calcul arbitraire avec une efficacité exponentiellement plus rapide que la vérification naïve du calcul. Les preuves d'intégrité computationnelle présentent les propriétés suivantes :

• Complétude : Une affirmation est vraie si un prouveur honnête peut convaincre un vérificateur honnête.
• Solidité : Si le prouveur est malhonnête, il ne peut pas tromper le vérificateur.
• Concision : La vérification est exponentiellement plus rapide que la vérification naïve du calcul.
• Divulgation nulle de connaissance : Aucune information n'est révélée au vérificateur.

Les ZKP s'appuient sur une transcription du calcul original étendue en une preuve à l'aide d'un code correcteur d'erreurs (par exemple, un code de Reed-Solomon, un engagement polynomial), qui propage toutes les erreurs au sein de la preuve. Un faible nombre de requêtes stochastiques par le vérificateur est suffisant pour prouver l'exactitude du calcul avec une forte probabilité (Figure 14.15).

Figure 14.15 Les ZKP peuvent être utilisées pour prouver l'exactitude des calculs. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

L'acronyme zk-SNARK signifie « zero-knowledge succinct non-interactive argument of knowledge » (argument de connaissance succinct non interactif à divulgation nulle de connaissance). Un zk-SNARK est une preuve cryptographique qui permet à une partie de prouver qu'elle possède certaines informations sans les révéler. La preuve est rendue possible en utilisant une clé secrète créée avant que la transaction ne se produise. zk-SNARK est utilisé dans le protocole de la cryptomonnaie Zcash. Dans une preuve non interactive, le dialogue interactif entre le prouveur et le vérificateur est remplacé par le caractère aléatoire. Les emplacements des requêtes sont prédéfinis par le caractère aléatoire, que le prouveur ne peut pas influencer.

Les zk-SNARKs ne peuvent pas être appliqués directement aux problèmes de calcul. Les problèmes doivent d'abord être convertis dans la « bonne forme ». Cette forme est appelée un programme arithmétique quadratique, et la transformation du code d'une fonction en QAP est très complexe. Elle nécessite de transformer le calcul en un circuit algébrique et de le transformer en un système de contraintes de rang 1 qui peut ensuite être converti en un QAP. En plus du processus de conversion du code d'une fonction en QAP, un autre processus peut s'exécuter en parallèle de telle sorte que si vous avez une entrée pour le code, vous pouvez créer une solution correspondante (parfois appelée « témoin » du QAP). Une fois cela fait, un autre processus assez complexe doit être suivi pour créer la véritable « preuve à divulgation nulle de connaissance » pour le témoin et un processus distinct pour vérifier la preuve que quelqu'un d'autre vous transmet. L'ensemble de la machinerie des zk-SNARKs est illustré dans la Figure 14.16.

Figure 14.16 L'ensemble de la machinerie des zk-SNARKs comprend le calcul, le circuit algébrique, le R1CS, le QAP, le PCP linéaire et la preuve interactive linéaire. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Les zk-SNARKs ne sont pas transparents et nécessitent une configuration dite « de confiance » pour sécuriser le caractère aléatoire des paramètres déterminant la sélection des requêtes dans la procédure de vérification. Les paramètres aléatoires sont, par exemple, générés à l'aide d'une fonction de hachage. Cependant, la connaissance des valeurs originales introduites dans la fonction de hachage (« déchets toxiques ») doit être gardée secrète. Sinon, il serait possible de récupérer les paramètres aléatoires et de manipuler la sélection des requêtes de vérification. Une configuration de confiance est un calcul multipartite (MPC ; « cérémonie »), qui génère récursivement des paramètres aléatoires. Si au moins une partie est honnête et oublie ses valeurs d'entrée, le caractère aléatoire de la configuration de confiance est sûr. Des configurations de confiance universelles peuvent être générées une fois et réutilisées pour d'autres applications ; les configurations non universelles sont liées au circuit spécifique. La partie difficile est de générer un zk-SNARK avec des ressources raisonnables pour des applications du monde réel.

Les zk-STARKs sont un type de ZKP où une partie peut prouver à une autre qu'une affirmation donnée est vraie sans révéler aucune autre information que le fait que l'affirmation est vraie. Les attributs du concept zk-STARK sont les suivants :

• divulgation nulle de connaissance (fait référence à la préservation de la confidentialité (privacy))
• extensibilité (scalability) (indique que le temps de vérification est considérablement inférieur au temps pris pour les calculs naïfs)
• transparence (reflète l'absence d'exigence de configuration de confiance)
• argument et connaissance (liés à la sécurité et à la robustesse du schéma cryptographique).

Les zk-STARKs fonctionnent en tirant parti d'une cryptographie plus légère, spécifiquement des fonctions de hachage résistantes aux collisions, pour valider la véracité d'une affirmation sans en partager les détails. Contrairement aux zk-SNARKs, qui reposent sur une configuration de confiance initiale et sont théoriquement vulnérables aux attaques des ordinateurs quantiques, les zk-STARKs éliminent ces problèmes. Cela dit, il est important de noter que cette approche plus légère entraîne un inconvénient significatif. Plus précisément, les zk-STARKs génèrent des preuves qui sont généralement 10 à 100 fois plus grandes que celles créées par les zk-SNARKs, ce qui les rend plus coûteuses et potentiellement moins pratiques pour certaines applications.

Les compromis entre les différentes propriétés des différents systèmes de preuve non interactifs et transparents se traduisent par une différence de temps de vérification, de temps de prouveur (1 s à 100 s) et de taille de preuve.

Les primitives cryptographiques utilisées par les ZKP incluent les primitives cryptographiques suivantes :

• Fonction de hachage résistante aux collisions (sécurité quantique) : STARK, Fractal, Aurora
• Cryptographie à courbe elliptique : Bulletproofs, Halo
• Connaissance des groupes d'exposants/de couplage : Groth16, Sonic, Marlin, PLONK
• Groupes d'ordre inconnu : Supersonic
• Cryptographie basée sur les réseaux (sécurité quantique) : en développement

Il existe une myriade d'applications récentes des ZKP à la technologie de la chaîne de blocs pour des améliorations de la confidentialité (privacy) et de l'extensibilité. Un sujet connexe est celui des fonctions de délai vérifiables, apparues en juin 2018. Une fonction de délai vérifiable est une fonction f : X → Y qui prend un temps minimum prescrit pour être calculée (même sur un ordinateur parallèle). Cependant, une fois calculée, n'importe qui peut rapidement vérifier le résultat. Elles peuvent empêcher la fraude ou le frontrunning sur les bourses, les enchères en ligne, les jeux ou les marchés de prédiction. Un autre sujet connexe est celui des calculs multipartites, qui sont des méthodes permettant aux parties de calculer conjointement une fonction sur leurs entrées tout en gardant ces entrées privées. Les MPC sont différentes des tâches cryptographiques traditionnelles qui utilisent la cryptographie pour assurer la sécurité et l'intégrité de la communication ou du stockage et supposent que l'adversaire est en dehors du système de participants. Dans les MPC, la cryptographie protège la confidentialité des participants les uns des autres. Un exemple d'application est celui d'une cérémonie de configuration de confiance, qui est un MPC sécurisé.

Un sujet connexe important est le chiffrement entièrement homomorphe, le « Saint Graal de la cryptographie ». Le FHE permet des opérations mathématiques arbitraires sur des données chiffrées (c'est-à-dire, pour chaque f : y = f(x) -> Chiffré y′ = f(x′)).

Problèmes ouverts en cryptographie

Les attaques continues et la nécessité de défendre les schémas cryptographiques exigent de rester au fait des meilleures pratiques. Idéalement, les développeurs devraient écrire du code qui peut être facilement modifié. N'oubliez pas non plus de ne pas développer vos propres mécanismes cryptographiques. Passez par l'examen par les pairs et appliquez le principe de Kerckhoff. N'implémentez même pas la cryptographie sous-jacente, et n'utilisez pas de manière abusive la cryptographie existante.

Des informations sur une implémentation particulière pourraient fuiter (par exemple, consommation d'énergie, rayonnement électromagnétique, synchronisation, erreurs). Les attaques basées sur cela sont appelées « attaques par canal auxiliaire ». Par exemple, une analyse de puissance simple peut être utilisée pour interpréter les traces de puissance pendant une opération cryptographique. L'analyse de puissance simple (Figure 14.17) peut révéler la séquence d'instructions qui ont été exécutées.

Figure 14.17 L'analyse de puissance simple peut révéler des instructions spécifiques telles que celles présentées ici. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

En supposant que le chemin d'exécution du programme dépend des entrées (c'est-à-dire clé/données), la SPA peut être utilisée pour révéler les clés. Contrairement à la SPA, qui inspecte visuellement une seule exécution, l'analyse de puissance différentielle peut fonctionner de manière interactive et réactive sur plusieurs échantillons. En utilisant cette approche, la DPA peut produire de nouveaux messages en clair qui peuvent être passés en entrée de manière répétée.

Afin de contrer ces types d'attaques, il est nécessaire de masquer les informations en veillant à ce que les chemins d'exécution ne dépendent pas fortement des entrées. Cela peut nécessiter d'abandonner les optimisations qui dépendent de valeurs de bits spécifiques dans les clés. Dans le passé, les optimisations du théorème des restes chinois ont permis des attaques temporelles à distance sur les serveurs Secure Socket Layer (SSL). En général, les systèmes cryptographiques devraient être conçus pour résister aux fuites d'informations.

Un autre type d'attaque par canal auxiliaire se produit lorsque les clés sont stockées en toute sécurité en mémoire, et que les attaquants n'ont pas accès à une machine. Dans ce cas, si l'attaquant peut accéder à la machine physique et la redémarrer dans un système d'exploitation qu'il contrôle, il devient possible pour l'attaquant d'examiner le contenu de la mémoire. Bien que la mémoire perde son état sans contenu, elle le fait beaucoup plus lentement à très basse température. Par conséquent, un attaquant pourrait refroidir la mémoire, éteindre la machine, déplacer la mémoire vers une autre machine et la démarrer dans un autre système d'exploitation. Il ne reste plus qu'à scanner l'image mémoire à la recherche de clés, ce qui est difficile mais faisable, en supposant que les clés ont un format facile à détecter. Quelques techniques peuvent être utilisées pour contrer ces types d'attaques. Une solution consiste à chiffrer toute la mémoire, ce qui nécessite une puissance de CPU supplémentaire. Une autre solution, utilisée sur Xbox, nécessite un module de plateforme de confiance (TPM) pour stocker les clés matérielles, ce qui rend leur installation très difficile. Certains TPM s'autodétruisent en cas de falsification ou conservent les clés en mémoire pendant une durée limitée (par exemple, les clés sont supprimées de la mémoire lors du passage en mode veille).

Il existe de nouveaux mécanismes pour permettre de nouveaux types d'interactions. Un style d'interaction qui a reçu beaucoup d'attention est le suivant :

• Alice possède des données propriétaires.
• Bob possède du code propriétaire.
• L'objectif est que Bob exécute son code sur les données d'Alice sans apprendre son entrée ni la sortie.

Des problèmes introduits précédemment nécessitent encore des solutions utilisables :

• Calcul multipartite sécurisé : Par exemple, Alice et Bob ont tous deux des données et veulent connaître le résultat d'une fonction sur leurs données privées sans avoir à se révéler leurs données mutuellement (par exemple, « qui de nous a plus d'argent » sans avoir à révéler exactement combien chacun a).20 Les frais généraux de communication et la vulnérabilité aux attaques de parties en collusion sont les principaux défis. Bien qu'il existe des techniques pour résoudre ces problèmes, elles s'accompagnent généralement de coûts de calcul plus élevés.
• Chiffrement entièrement homomorphe : Le chiffrement homomorphe peut effectuer des calculs sur des données chiffrées sans les déchiffrer d'abord avec une clé secrète. Il chiffre ensuite les résultats du calcul, et seul le propriétaire ou la clé privée peut les déchiffrer.21 Les systèmes HE partiels existent depuis les années 1970, et un schéma HE entièrement homomorphe qui permet d'appliquer des opérations mathématiques à des données chiffrées a été développé pour la première fois par Craig Gentry en 2009. Cependant, le chiffrement entièrement homomorphe sous sa forme actuelle est d'une lenteur impraticable.

Sécurité logicielle

Les architectes et développeurs de solutions logicielles doivent considérer la sécurité comme une propriété des systèmes qu'ils construisent. De nombreuses attaques commencent par l'exploitation d'une vulnérabilité. Dans ce cas, une vulnérabilité est un défaut logiciel qui entraîne un comportement indésirable (c'est-à-dire que le code ne se comporte pas correctement). Les défauts logiciels résultent de failles de conception ou de bogues dans l'implémentation. Malheureusement, les logiciels ne peuvent pas être complètement exempts de bogues, et corriger chaque bogue connu peut être trop coûteux. En général, l'objectif est de corriger ce qui est susceptible d'affecter les utilisateurs normaux et de ne pas se concentrer sur les bogues que les utilisateurs normaux ne voient jamais ou évitent. Parce que les attaquants ne sont pas des utilisateurs normaux, ils recherchent les bogues et les failles et essaient de les exploiter. Par conséquent, pour assurer la sécurité logicielle, il est nécessaire d'éliminer les bogues et les failles de conception et/ou de rendre leur exploitation plus difficile. Pour ce faire, il faut penser comme des attaquants et développer une base pour une compréhension approfondie des systèmes construits et utilisés.

La plupart des logiciels (intéressants) prennent des entrées de diverses sources, et n'importe laquelle de ces entrées peut être malveillante, comme les suivantes :

• interaction directe de l'utilisateur (par exemple, l'utilisateur interagit avec le logiciel via une interface de ligne de commande ou ouvre un document)
• bibliothèques tierces liées au logiciel
• futures mises à jour de code

La sécurisation des logiciels dans ce contexte devrait aboutir à un fonctionnement correct malgré des entrées malveillantes. Afin d'étudier comment sécuriser les logiciels, nous nous concentrerons sur ce qui devrait être fait pour sécuriser les logiciels écrits en langage de programmation C et enquêter sur le détournement du flux de contrôle du programme via les débordements de tampon, l'injection de code et d'autres vulnérabilités de sécurité de la mémoire. Ceci est motivé par le fait que le langage C est constamment largement utilisé, et de nombreux systèmes critiques sont écrits en C (par exemple, la plupart des noyaux de systèmes d'exploitation tels que Linux, les serveurs hautes performances tels que Microsoft SQL Server, de nombreux systèmes embarqués tels que Mars rover). De plus, les mêmes techniques s'appliquent plus largement.

Attaques et défenses par débordement de tampon

De nombreuses attaques par débordement de tampon ont été perpétrées au fil des ans contre des programmes logiciels écrits en C. Les débordements de tampon sont répandus et constituent un pourcentage significatif de toutes les vulnérabilités.22 En 1988 par exemple, Robert Morris a envoyé une chaîne spéciale via une attaque par débordement de tampon au démon fingered sur un ordinateur exécutant le système d'exploitation VAX et l'a fait exécuter du code qui a créé une copie de ver qui s'est propagée sur le réseau et a affecté les machines Sun exécutant les systèmes d'exploitation BSD. Cela a entraîné 100 millions de dollars de dommages ainsi qu'une probation et des services communautaires. Robert Morris est ensuite devenu professeur au MIT. En 2001, le ver Code Red a exploité une erreur de débordement de tampon dans le serveur MS-IIS. En conséquence, 300 000 machines ont été infectées en 14 heures. En 2003, le ver SQL Slammer a exploité une erreur de débordement de tampon similaire dans le serveur MS-SQL. En conséquence, 75 000 machines ont été infectées en dix minutes. En 2008-2009, le ver Conficker a exploité un débordement de tampon dans Windows RPC, qui a infecté plus de dix millions de machines. En 2009-2010, Stuxnet a exploité plusieurs débordements de tampon dans le service de spouleur d'impression Windows, l'affichage de raccourcis LNK, le planificateur de tâches et le même débordement de tampon RPC que Conficker, ce qui a conduit à une véritable cyberguerre. Entre 2010 et 2012, Flame a exploité les mêmes débordements de spouleur d'impression et LNK que Stuxnet, ce qui a entraîné un virus d'espionnage cybernétique. Le 8 janvier 2014, un jeune de 23 ans a découvert une vulnérabilité de débordement de tampon de pile de sécurité du serveur X11 (c'est-à-dire scanf utilisé lors du chargement de polices bitmap BDF du début des années 1990) datant de 1991. La vulnérabilité GHOST glibc a été introduite en 2000 mais n'a été découverte que de nombreuses années plus tard. Un dernier exemple est le bogue du démon d'infrastructure de journalisation Syslog dans macOS et iOS, qui reposait sur le fait que les programmes en cours d'exécution émettaient des messages de journal et que Syslog se chargeait de les stocker et de les diffuser. Le problème était que Syslog utilisait un tampon pour propager ces messages, qui n'était pas assez grand et écrivait parfois au-delà de la fin du tampon.

Sur cette base, comprendre le fonctionnement des attaques par débordement de tampon des programmes C et comment s'en défendre est essentiel et nécessite des connaissances (voir Chapitre 4 Réalisation linguistique des algorithmes : langages de programmation de bas niveau et Chapitre 5 Réalisations matérielles des algorithmes : conception des systèmes informatiques) du compilateur logiciel C, du système d'exploitation sur lequel le programme est exécuté et de l'architecture du système informatique sur laquelle le système d'exploitation s'exécute — en d'autres termes, une vue d'ensemble des systèmes. Pour rappel, la disposition de la pile sur un ordinateur 32 bits lors de l'appel d'une fonction C exemple (Figure 14.18) est présentée. Notez que dans ce cas, il y a deux valeurs de 4 octets entre les arguments et les variables locales.

Figure 14.18 Les variables de fonction locales sont empilées sur la pile dans l'ordre où elles apparaissent dans le code, tandis que les arguments de fonction sont empilés dans l'ordre inverse de leur apparition dans le code. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

La fonction func peut accéder à la variable loc2, en utilisant le pointeur de cadre de pile %ebp (Figure 14.19). Notez que la même chose s'appliquerait sur un ordinateur 64 bits en utilisant une disposition de mémoire 64 bits et en changeant les noms des registres en conséquence (par exemple, %rbp vs %ebp).

Figure 14.19 L'emplacement de la variable loc2 dans le cadre de pile est toujours 8 octets avant l'adresse contenue dans %ebp. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Figure 14.20 illustre comment retourner correctement d'un appel à la fonction func.

Figure 14.20 Cette figure montre comment retourner correctement d'un appel à la fonction

func

. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

En résumé, les étapes à suivre pour appeler et retourner d'une fonction sont les suivantes :

Appel de fonction :

1. Pousser les arguments sur la pile.
2. Pousser l'adresse de retour sur la pile (c'est-à-dire l'adresse de l'instruction qui doit être exécutée une fois que le contrôle revient au programme appelant : %eip + quelque chose).
3. Sauter à l'adresse de la fonction.
   Fonction appelée :
4. Pousser l'ancien pointeur de cadre sur la pile : %ebp.
5. Définir le pointeur de cadre %ebp à l'endroit où se trouve la fin de la pile à ce moment : %esp.
6. Pousser les variables locales sur la pile ; y accéder comme des décalages par rapport à %ebp.
   Fonction de retour :
7. Réinitialiser le cadre de pile précédent : %ebp = (%ebp) /* copier d'abord */.
8. Retourner à l'adresse de retour : %eip = 4(%ebp) /* utiliser la copie */.

Examinons un exemple de débordement de tampon basé sur la compréhension de la disposition de la mémoire de la pile lors de l'appel et du retour de fonctions. Les tampons sont couramment utilisés en C pour stocker des ensembles de valeurs d'un type de données donné. Par exemple, les chaînes sont des tampons de caractères en C. Un débordement de tampon se produit lorsque plus de valeurs sont placées dans le tampon qu'il ne peut en contenir. Considérons cet exemple de débordement de tampon (Figure 14.21) et juste avant l'exécution de l'instruction « strcpy; » dans la fonction func.

Figure 14.21 L'instruction strcpy exécutée dans la fonction

func

déborde la taille du tampon spécifié. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Une fois l'instruction « strcpy; » exécutée dans la fonction func (Figure 14.22), elle écrase l'emplacement mémoire de la pile où %ebp était stocké, ce qui provoque une violation de segmentation lorsque la fonction retourne.

Figure 14.22 L'instruction strcpy exécutée dans la fonction

func

définit %ebp à la mauvaise adresse au retour en raison du débordement de tampon. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

L'utilisation du débogueur GNU (c'est-à-dire gdb) est utile pour déboguer les programmes qui rencontrent des débordements de tampon. Il permet aux utilisateurs d'afficher des informations sur le cadre et les registres actuels, d'examiner des octets de mémoire à partir d'une adresse donnée, de définir un point d'arrêt à une adresse de fonction donnée et de parcourir un appel à celle-ci.

Une version sécurisée de la fonction func ne causera jamais de débordement de tampon. Elle limitera simplement le nombre de caractères lus depuis la ligne de commande et pourrait être facilement adaptée pour remplacer la fonction func :

    Void nooverflow()
    {
      char buflimit[100];
      fgets (buflimit,
      sizeof);
    }
    

Notez que strcpy vous permet d'écrire autant de caractères que vous le souhaitez jusqu'à ce qu'il lise un caractère de fin de chaîne (c'est-à-dire le caractère nul « \0 » dans une chaîne C) ; par conséquent, le problème pourrait être pire que le simple écrasement de %ebp. La Figure 14.23 illustre un type différent de débordement de tampon qui se produirait si la fonction func devait exécuter le code fourni. Dans ce cas, l'entrée écrit des adresses basses vers les adresses hautes.

Figure 14.23 L'exécution du code montré est telle que l'entrée écrit des adresses basses vers les adresses hautes. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Attaques et défenses par injection de code

L'exemple de débordement de tampon montré précédemment utilise une chaîne fournie par le programme lui-même mais, en général, les entrées pourraient provenir de différentes sources (par exemple, saisie de texte, paquets réseau, variables d'environnement, entrées de fichiers). Par conséquent, l'existence d'un bogue de débordement de tampon dans un programme peut conduire à une attaque par injection de code (Figure 14.24).

Figure 14.24 Une attaque par injection de code peut être mise en scène en chargeant du code en mémoire et en faisant pointer %eip vers celui-ci. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Réaliser ce type d'attaque nécessite de surmonter quelques défis, que nous discuterons en détail. En général, rendre très difficile de surmonter les divers défis est essentiel pour défendre les programmes contre les attaques par injection de code. Les défis sont les suivants :

1. Chargement du code en mémoire :
   Le code chargé en mémoire doit être du code machine prêt à être exécuté. Il ne doit pas contenir d'octets entièrement nuls. Alternativement, certaines fonctions de bibliothèque arrêteront la copie. Le chargeur ne peut pas être utilisé car le code est injecté. Enfin, le code injecté ne peut pas utiliser la pile car il est conçu pour la détruire.
   Le meilleur type de code pour cela est un shellcode polyvalent qui peut être lancé comme un shell (Figure 14.25). Il existe de nombreux exemples de ce type de code, et il y a beaucoup de concurrence pour écrire la plus petite quantité de code. De plus, un moyen de s'assurer que le code injecté fonctionnera le plus efficacement est de tenter une élévation de privilèges et de passer de l'état d'invité à celui de root.
   

   

   Figure 14.25 Le meilleur type de code pour l'injection de code est un shellcode polyvalent qui peut être lancé comme un shell. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)
   
   Concernant l'élévation de privilèges, l'idée est d'exploiter la connaissance des permissions sur le système d'exploitation ciblé. Dans le cas de Linux, les fichiers ont des permissions de lecture/écriture/exécution pour le propriétaire, le groupe et les autres. Les permissions sont définies pour l'userid et le groupid, et l'userid root est p. La commande passwd peut être utilisée dans le cadre d'une attaque en permettant à tout utilisateur d'exécuter cette commande plutôt que seulement son propriétaire (c'est-à-dire root). L'idée est d'avoir un processus appartenant à root qui exécute setuid(0) ou seteuid(0) afin d'obtenir les permissions root. Bien que root possède « passwd », les utilisateurs peuvent l'exécuter, et getuid() renverra l'userid de la personne qui l'a exécuté. L'exécution de seteuid(0) ensuite définira l'userid effectif à root, ce qui est autorisé car root est le propriétaire du processus.
2. Exécution du code injecté :
   Comme il n'est possible d'écrire qu'en avant dans un tampon mémoire, le code en cours d'exécution doit déjà être utilisé pour sauter au code injecté. L'approche typique consiste à détourner le %eip sauvegardé et à le modifier pour qu'il pointe vers l'adresse du code injecté (Figure 14.26).
   

   

   Figure 14.26 L'injection de code est effectuée en détournant le %eip sauvegardé et en le modifiant pour qu'il pointe vers l'adresse du code injecté. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)
   
   Cependant, connaître l'adresse du %eip sauvegardé est un défi. De plus, si le %eip est incorrect et pointe vers des données, le CPU paniquera lorsqu'il tentera d'exécuter une instruction invalide.
3. Recherche de l'adresse de retour :
   Comme le code n'est pas accessible, il n'y a aucun moyen de savoir où commence le tampon en se basant sur le %ebp sauvegardé. Une possibilité est d'essayer beaucoup de valeurs différentes, et la situation du pire cas pour un espace mémoire de 64 bits implique de calculer 2⁶⁴ réponses possibles. Si la randomisation de l'agencement de l'espace d'adresses est désactivée, ce sur quoi vous ne pouvez pas compter aujourd'hui, la pile commence toujours à la même adresse fixe et se développe ensuite. Cependant, elle ne se développe généralement pas très profondément à moins que le code ne soit fortement récursif.
   Une autre approche consiste à utiliser des nop sleds. Comme nop est une instruction d'un seul octet, elle permet de passer à l'instruction suivante, améliorant ainsi les chances d'atteindre l'adresse de %eip (Figure 14.27).
   

   

   Figure 14.27 L'introduction d'instructions nop à un seul octet améliore les chances d'atteindre l'adresse de %eip. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Enfin, en mettant tout cela ensemble, la recette de l'injection de code est d'obtenir ce qui est montré dans la Figure 14.28.

Figure 14.28 La recette de l'injection de code consiste à deviner l'adresse de retour de la pile et à utiliser des nop sleds pour améliorer les chances d'atteindre l'adresse de %eip. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Une façon typique de protéger un programme contre l'injection de code est d'empêcher l'exécution de données en marquant les pages mémoire comme non exécutables ou de rendre impossible l'insertion de code en mémoire en détectant les débordements avec des canaris. L'utilisation d'un canari consiste à placer une chaîne de caractères connue en mémoire à la fin du tampon et à interrompre l'exécution du programme si la valeur attendue à cet emplacement est modifiée (Figure 14.29).

Figure 14.29 Placer un canari à la fin du tampon permet de détecter si le contenu à la fin du tampon a été modifié. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Il existe quelques possibilités pour les valeurs de canari comme indiqué :

1. Les canaris terminateurs exploitent le fait que scanf et d'autres fonctions similaires n'autorisent pas ces valeurs.
2. Les canaris aléatoires écrivent une nouvelle valeur aléatoire au démarrage de chaque processus et sauvegardent la valeur réelle quelque part en mémoire ; il est nécessaire de protéger en écriture la valeur stockée dans ce cas.
3. Les canaris XOR aléatoires fonctionnent de la même manière que les canaris aléatoires mais stockent « canari XOR <some control info> » à la place.

int func (char *user)
{
    printf;
}

int func (char *user)
{
    printf ("%s", user);
}

Problème du temps de vérification/temps d'utilisation

Figure 14.30 illustre le problème du temps de vérification/temps d'utilisation.

Figure 14.30 L'accès est destiné à vérifier si l'utilisateur réel qui a exécuté le programme setuid serait normalement autorisé à lire le fichier, de sorte que l'accès vérifie l'uid réel au lieu de l'userid effectif euid. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Le code devrait être modifié comme dans la Figure 14.31 pour éviter le problème TOCTOU.

Figure 14.31 Le code est modifié pour basculer l'utilisateur qui a exécuté la commande setuid vers l'utilisateur effectif afin de garantir que les permissions appropriées sont utilisées lors de l'accès au document. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Défenses courantes contre les cybermenaces

Les cybermenaces courantes ont été introduites précédemment avec divers exemples de maliciels. La protection contre les maliciels implique l'utilisation d'un système de détection d'intrusion (IDS) ainsi que d'un système de prévention d'intrusion (IPS). Un IDS peut être basé sur l'hôte ou sur le réseau (c'est-à-dire HIDS ou NIDS). Dans ce cas, la détection se produit après l'attaque (c'est-à-dire que la mémoire est déjà corrompue en raison d'une attaque par débordement de tampon). Une mesure préventive doit arrêter l'attaque avant qu'elle n'atteigne le système (c'est-à-dire que le bouclier effectue un filtrage de paquets). Certains outils prennent en charge à la fois l'IDS et l'IPS.

Méthodes de détection des maliciels

En général, certains types de maliciels peuvent reposer sur un certain délai basé sur un déclencheur pour s'exécuter (par exemple, bombe à retardement, bombe logique), et ils peuvent inclure une porte dérobée pour servir de rançon. D'autres types de maliciels s'accrochent à d'autres morceaux de code. Par exemple, les virus s'exécutent lorsque les utilisateurs lancent une tâche (par exemple, exécutent un programme, ouvrent une pièce jointe, démarrent la machine). Les vers s'exécutent pendant qu'un autre programme est en cours d'exécution et ne nécessitent pas d'intervention de l'utilisateur. Par conséquent, un virus se propage en s'assurant qu'il est finalement exécuté, en supposant une intervention de l'utilisateur. Une fois exécuté, le virus crée une nouvelle instance distincte de lui-même et infecte généralement en altérant le code stocké. Un ver se propage en s'assurant qu'il est immédiatement exécuté sans intervention de l'utilisateur. Une fois exécuté, le ver crée une nouvelle instance distincte de lui-même, et il infecte généralement en altérant le code en cours d'exécution. Il y a une ligne fine entre les virus et les vers ; certains maliciels utilisent les deux types.

La détection des maliciels auto-propageants est difficile. Alors que les logiciels antivirus tentent de détecter les virus, les auteurs de virus s'efforcent d'échapper à la réponse humaine et d'éviter la détection aussi longtemps que possible. Dans le cas des vers, l'auteur du virus veut propager le ver et atteindre de nombreuses machines aussi rapidement que possible pour devancer la réponse humaine. Les virus existent depuis les années 1970. Ils sont opportunistes et s'exécutent finalement à la suite d'une action de l'utilisateur. Deux aspects orthogonaux définissent un virus : la manière dont il se propage et ce qu'il fait (c'est-à-dire la « charge utile »). Une stratégie d'infection générale consiste à modifier le code existant pour incorporer le virus, le partager et s'attendre à ce que les utilisateurs le partagent. Les virus infectent d'autres programmes en prenant le contrôle de leur point d'entrée afin que le virus soit exécuté lors de l'exécution de ces programmes. Ils infectent des documents, des secteurs de démarrage ou s'exécutent comme du code résidant en mémoire. Ils augmentent leurs chances d'exécution en attachant du code malveillant à un programme qu'un utilisateur est susceptible d'exécuter (par exemple, des pièces jointes de courriel). Une fois que les virus s'exécutent, ils recherchent également une opportunité d'infecter d'autres systèmes (par exemple, la création proactive de courriels).

Une méthode évidente pour détecter les virus est d'utiliser la détection basée sur les signatures, qui consiste à rechercher les octets correspondant au code viral injecté et à protéger d'autres systèmes en installant un reconnaisseur pour un virus connu en leur sein. Cette approche nécessite des algorithmes de balayage rapides et a conduit à la création d'un marché antivirus de plusieurs milliards de dollars. L'ajout de signatures reconnues à ce marché permet le marketing et conduit à la concurrence. Pour lutter contre cette méthode de détection, les auteurs de virus donnent aux virus des signatures plus difficiles à faire correspondre en créant des virus polymorphes. Dans ce cas, le virus génère une version sémantiquement différente du code chaque fois qu'il se propage. Alors que la sémantique de haut niveau du virus reste la même, le code d'exécution réel diffère (par exemple, les instructions de code machine sont différentes, différents algorithmes sont utilisés pour atteindre le même objectif, le code utilise différents registres, ou différentes constantes sont utilisées). Cela peut être accompli en incluant un réécrivain de code avec un virus ou en ajoutant un code complexe qui ne s'exécute jamais pour échapper aux tentatives de détection. Au lieu d'ajouter le programme au virus, les auteurs de virus entourent le programme de code viral, ou écrasent des parties du programme rarement utilisées afin de confondre les scanners de virus. Ils modifient également le code viral afin que les scanners ne puissent pas identifier une signature. Les modifications de code peuvent être mécanisées de sorte que le code semble différent chaque fois qu'il est injecté. Pour ce faire, ils utilisent le chiffrement à clé publique (et le fait qu'il est non déterministe) pour générer un code viral différent chaque fois qu'ils chiffrent le virus. En même temps, le déchiffrement produit toujours le même code viral (Figure 14.32). Les auteurs de virus obfusquent également itérativement le code (c'est-à-dire chiffrement + jmp + ...) en utilisant différents algorithmes de chiffrement jusqu'à ce que le code obfusqué soit entièrement indétectable.

Figure 14.32 Les auteurs de virus génèrent un code viral différent chaque fois qu'ils chiffrent le virus, tandis que le déchiffrement produit toujours le même code viral. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Le balayage est insuffisant pour détecter les virus métamorphiques, et une détection appropriée nécessite une analyse du comportement d'exécution du code. Deux approches générales peuvent être appliquées pour faciliter la détection, et toutes deux doivent être menées dans un environnement sûr. L'une des approches utilisées par les entreprises antivirus se concentre sur l'analyse d'un nouveau virus pour localiser sa signature comportementale. Une autre approche se concentre sur l'analyse de code suspect pour voir s'il correspond à la signature. En général, les attaquants ont l'avantage car les systèmes antivirus partagent des signatures, ce qui fournit des informations que les attaquants peuvent utiliser pour réagir. Les attaquants modifient lentement les virus pour rendre difficile la création d'une signature comportementale correspondante ou ils peuvent commencer à agir différemment pour éviter la détection. Afin de détecter les virus polymorphes, les auteurs d'antivirus peuvent enregistrer des signatures étroites utilisées par les auteurs de virus pour attraper les déchiffreurs associés. Comme ces signatures sont souvent très petites, cette approche peut entraîner de nombreux faux positifs. Pour contrer cette approche, les attaquants peuvent disperser un petit code de déchiffrement et utiliser une instruction jmp pour atteindre le code viral. Une autre approche pour détecter les virus polymorphes consiste à exécuter ou à analyser statiquement le code suspect pour voir s'il déchiffre. Le problème avec cette dernière approche est qu'il est difficile de différencier un virus chiffré d'un programme « packers » valide qui fait quelque chose de similaire (par exemple, la décompression). Cela dépend également de la durée pendant laquelle le code peut être exécuté sans effets secondaires. Les auteurs de virus peuvent combattre ces approches en modifiant le déchiffreur. Par exemple, les virus oligomorphes changent d'un ensemble fixe de déchiffreurs, et les vrais virus polymorphes peuvent générer un nombre infini de déchiffreurs. Bien que cette approche entraîne des inefficacités, elle rend extrêmement difficile la détection des virus par les logiciels antivirus.

Aujourd'hui, la détection des maliciels est une course aux armements technologique entre la détection et l'évitement. Initialement, seules quelques personnes très intelligentes étaient capables de créer des virus. Les virus sont maintenant banalisés, et n'importe qui peut en lancer un. La création de virus reste difficile. Cependant, ce n'est plus un centre d'intérêt académique, mais est plutôt motivée par des objectifs économiques (par exemple, les marchés du jour zéro) et la cyberguerre.

Méthodologies d'assurance des solutions logicielles

Comme discuté précédemment, la sécurité logicielle peut être compromise à la suite d'attaques de sécurité de la mémoire qui incluent les suivantes :

• les débordements de tampon, qui peuvent être utilisés pour lire/écrire des données sur la pile/le tas ou pour injecter du code ;
• les erreurs de chaîne de format, utilisées pour lire/écrire des données de pile ;
• les erreurs de débordement d'entiers, utilisées pour modifier le flux de contrôle des programmes ; et
• les problèmes TOCTOU, utilisés pour élever les privilèges.

Diverses méthodologies et approches associées qui peuvent être utilisées dans le cadre du cycle de vie du développement logiciel pour prévenir ces attaques sont décrites dans les sections suivantes.

Implémentation logicielle sécurisée

La base informatique de confiance de chaque système peut inclure le moniteur, le compilateur, le système d'exploitation, le CPU, la mémoire, le clavier et d'autres périphériques. La sécurité de base suppose une TCB correcte, complète et sécurisée. Une bonne TCB est petite et sépare les privilèges. L'utilisation d'une TCB petite et simple garantit que moins de composants doivent fonctionner correctement pour assurer la sécurité et sont moins susceptibles d'être compromis. À mesure que les logiciels de sécurité dans la TCB augmentent et deviennent plus complexes (par exemple, les noyaux de systèmes d'exploitation utilisés pour appliquer la sécurité incluent souvent une grande quantité de code), ils deviennent vulnérables et peuvent être contournés. Plutôt que de compromettre la sécurité d'un pilote de périphérique, il est préférable de réduire la taille du noyau du système d'exploitation en créant des micro-noyaux qui exploitent les pilotes de périphérique situés en dehors du noyau. Le principe du moindre privilège, une approche de séparation des privilèges, devrait également être appliqué pour maintenir les modules d'opérations privilégiées aussi petits que possible. Il est important de ne donner que le niveau de privilège approprié à une tâche. Il n'y a aucune raison de donner plus de privilèges que nécessaire à une tâche. Par exemple, il n'est pas nécessaire qu'un démon de serveur web autorise root à se lier au port 80. Cela permettrait au serveur web de s'exécuter en tant que root. De même, les éditeurs de courrier électronique ne devraient pas permettre d'accéder à un shell. Vous devez vous rappeler que la confiance est transitive, faire confiance à quelque chose signifie que vous faites confiance à ce qu'il fait confiance, ce qui peut entraîner des problèmes.

Penser à la sécurité du code est essentiel pour garantir la sécurité et l'exactitude du code. La modularité du code est importante car elle aide à gagner en confiance dans le code fonction par fonction et module par module. Il est nécessaire de vérifier que les pré- et post-conditions sont respectées avant et après l'appel d'une fonction, respectivement. Cela aide à définir des contrats pour l'utilisation des modules (par exemple, la post-condition d'une instruction donnée doit correspondre à la pré-condition d'une autre instruction). Les pré- et post-conditions aident à documenter le code et facilitent le raisonnement sur le code. Les invariants aident à établir des conditions qui sont toujours vraies au sein de certaines parties d'une fonction. Toutes les techniques de programmation défensive susmentionnées permettent de vérifier les fonctions basées sur le code et les annotations associées chaque fois que le code est invoqué. La programmation défensive permet de raisonner sur la sécurité des fonctions chaque fois qu'elles sont appelées, et les pré-conditions agissent comme des contraintes que les utilisateurs doivent respecter chaque fois qu'ils utilisent des fonctions.

Le code suivant illustre les préconditions nécessaires pour assurer la sécurité. L'approche consiste à identifier chaque accès à la mémoire et à les annoter avec les préconditions qu'ils requièrent et à propager ces exigences vers le haut.

(source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Dans cet exemple, l'accès à la mémoire a conduit aux annotations suivantes33 :

/* requires: a != NULL        */
/* requires: Ø <= i         */
/* requires: i < size(a)        */

La deuxième annotation est prise en charge par size_t i, ce qui garantit que 0 <= i est toujours vrai. Les deux autres annotations n'étaient pas garanties par le code de cette fonction, elles ont donc été remontées en tant que préconditions pour s'assurer que n <= size(a).

Voici un autre exemple des vérifications de pré- et post-conditions nécessaires lors de l'utilisation ou de la création de pointeur respectivement pour assurer la sécurité34 :

/* requires: p != NULL */
/* ensures: retval is the first four bytes p pointed to */
int deref(int *p) {
  return *p;
}
/* ensures: retval != NULL */
void *myalloc(size_t n) {
  void *p = malloc(n);
  if (!p) {
    perror("malloc");
    exit(1);
  }
  return p;
}

Tests

L'objectif des tests de qualité du logiciel est de s'assurer que la spécification et l'implémentation des programmes correspondent. De plus, les tests supposent que la spécification est correcte, mais ils ne supposent pas nécessairement que l'implémentation est correcte.

Les développeurs ne devraient pas être des testeurs de bout en bout. Un développeur devrait se concentrer sur l'implémentation et les tests unitaires tandis qu'un testeur se concentre sur la spécification, ce qui évite les erreurs connexes aux deux niveaux.

Les approches de test peuvent être classées comme illustré dans la Figure 14.33.

Figure 14.33 Les approches de test peuvent être manuelles ou automatisées et tester les logiciels en utilisant des techniques de boîte noire ou de boîte blanche. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Comme illustré, il existe différentes manières de réaliser des tests. Les tests automatisés impliquent l'écriture de scripts ou l'utilisation de cadriciels de test pour simuler les interactions de l'utilisateur avec une application logicielle (par exemple, cliquer sur des boutons, saisir des données et vérifier les résultats). Cela améliore l'efficacité en automatisant les tâches de test répétitives, ce qui permet d'économiser un temps et des ressources précieux. Les tests automatisés améliorent également la précision en minimisant les erreurs humaines, et ils augmentent la couverture des tests en permettant les tests de régression et les tests et livraisons continus via les pipelines CI/CD. Les tests manuels supposent la création de suites de tests efficaces pour fournir une couverture de test optimale et peuvent avoir du mal à atteindre une couverture complète et une extensibilité en raison des contraintes de temps et de ressources. Les tests boîte noire ne nécessitent pas l'analyse du code, ce qui fonctionne bien pour le code qui ne peut pas être modifié ou qui est dans un format difficile à analyser (par exemple, code obfusqué, géré, ou code binaire). Les tests boîte blanche supposent une suite de tests efficace pour fournir les tests détaillés évaluant le code source.

Les suites de tests doivent être dimensionnées correctement. Un petit nombre de tests ne peut pas identifier tous les défauts, et un grand nombre de tests ralentira les tests et rendra leur maintenance plus difficile en raison du gonflement et de la redondance. Par exemple, la bibliothèque SQLite (version 3.20.0) comprenait environ 125,4 mille lignes de code source par rapport à un projet l'utilisant qui avait 730 fois plus de code et de scripts de test (c'est-à-dire 91616,0 KSLOC). Il convient de noter que les lignes de code KSLOC excluent les lignes vides et les commentaires.

La couverture de code est une métrique utilisée pour quantifier l'étendue des tests de programme lors de l'utilisation d'une suite de tests donnée. La couverture des tests de fonction se concentre sur les fonctions appelées. La couverture des tests d'instruction se concentre sur les instructions exécutées, et la couverture des tests de branche se concentre sur les branches exécutées. La couverture des tests est calculée en pourcentage des aspects de test d'un programme couverts par une suite de tests donnée. En pratique, tester 100 % du code d'un programme est impossible. La complexité cyclomatique fait référence au nombre de chemins qui existent dans un programme et qui devraient, en théorie, être testés. Cela dit, certains codes peuvent ne pas être accessibles, et même si des tests complets étaient possibles, cela pourrait prendre une quantité infinie de temps. Les applications critiques pour la sécurité nécessitent une couverture à 100 %. SQLite, par exemple, a une couverture de branche à 100 %.

Dans les tests boîte blanche manuels, les tests sont écrits à la main en utilisant une connaissance complète du code source/déploiement/infrastructure. Ils peuvent être automatisés (par exemple, exécutés sur toutes les sauvegardes ou tous les commits).

Dans les tests boîte noire manuels, le testeur interagit avec le système de manière boîte noire et élabore des entrées mal formées, les teste et enregistre la réaction du système.

Les techniques de tests automatisés incluent :

• Analyse de code
  • Statique : L'évaluation du code source peut identifier de nombreux bogues dont nous avons discuté.
  • Dynamique : Exécuter dans une machine virtuelle et rechercher les écritures invalides.
• Fuzz testing
  • Générer de nombreuses entrées aléatoires et voir si le programme échoue.
  • Typiquement, cela implique de nombreuses entrées.
  • Il existe différents types de fuzzing possibles :
    • Boîte noire : L'outil ne sait rien du programme ou de son entrée ; il est facile à utiliser et à démarrer, mais il n'explorera que des états superficiels à moins d'avoir de la chance.
    • Basé sur la grammaire : L'outil génère une entrée informée par la grammaire ; plus de travail est nécessaire pour l'utiliser et produire la grammaire, mais il peut aller plus profondément dans l'espace des états.
    • Boîte blanche : L'outil génère de nouvelles entrées au moins partiellement informées par le code du programme en cours de fuzzing ; il est souvent facile à utiliser mais coûteux en calcul.
  • Les entrées de fuzzing peuvent être fournies de différentes manières :
    • Mutation : Prendre une entrée légale et la muter, en l'utilisant comme entrée ; l'entrée légale peut être produite par l'homme ou automatisée (par exemple, à partir d'une grammaire ou d'une requête de solveur SMT) ; la mutation peut également être forcée de respecter la grammaire.
    • Générationnel : Générer une entrée à partir de zéro (par exemple, à partir d'une grammaire).
    • Combinaisons : Générer une entrée initiale, muter, générer de nouvelles entrées et générer des mutations selon la grammaire.
  • Le fuzzing basé sur les fichiers mute ou génère des entrées puis exécute le programme cible avec celles-ci pour voir ce qui se passe ; un exemple est Radamsa,35 un fuzzer boîte noire basé sur la mutation, qui mute les entrées données et les transmet36 :
    % echo "1 + (2 + (3 + 4))" | radamsa --seed 12 -n 4 5!++ (3 + -5)) 1 + (3 + 41907596644) 1 + (-4 + (3 + 4)) 1 + (2 + (3 + 4 % echo … | radamsa --seed 12 -n 4 | bc -1
    Un autre exemple est Blab, qui génère des entrées selon une grammaire (c'est-à-dire basée sur la grammaire), spécifiée comme des expressions régulières et des CFG37 :
    % blab -e '(([wrstp][aeiouy]{1,2}){1,4} 32}{5} 10' soty wypisi tisyro to patu
  • Le fuzzing basé sur le réseau peut agir comme la moitié d'une paire de communication ; les entrées pourraient être produites en rejouant une interaction précédemment enregistrée, en la modifiant, ou en la produisant à partir de zéro (par exemple, à partir d'une grammaire de protocole). Il peut également agir comme une « attaque de l'homme du milieu » en mutant les entrées échangées entre les parties (peut-être informées par la grammaire).
  • Il existe de nombreux fuzzers, tels que American Fuzzy Lop (fuzzer boîte blanche basé sur la mutation), SPIKE (bibliothèque pour la création de fuzzers basés sur le réseau), Burp Intruder (automatise les attaques personnalisées contre les applications web), BFF et Sulley. Les fuzzers aident à trouver la cause première d'un crash en répondant à des questions telles que : Existe-t-il une entrée plus petite qui provoque un crash au même endroit (ce qui facilite la compréhension) ? Y a-t-il plusieurs crashes qui renvoient au même bogue ? Pouvez-vous déterminer si un crash représente une vulnérabilité exploitable (en particulier, y a-t-il un dépassement de tampon) ?
  • Le fuzzing peut aider à trouver des erreurs de mémoire :
    Tout d'abord, compilez le programme avec AddressSanitizer, qui instrumente les accès aux tableaux pour vérifier les dépassements et les erreurs d'utilisation après libération, puis effectuez un fuzzing et vérifiez si le programme a planté avec une erreur signalée par ASan. Si c'est le cas, préoccupez-vous de l'exploitabilité ; de même, vous pouvez compiler avec d'autres types de vérificateurs d'erreurs pour les tests.
• Les tests boîte noire automatisés utilisent les composants de fuzzing comme expliqué pour générer des cas de test, exécuter les applications et effectuer la détection et la journalisation.
• Dans les tests boîte blanche automatisés, les tests sont créés automatiquement/dynamiquement. Des outils existent pour effectuer ce type de tests et peuvent enregistrer une trace du programme testé sur des entrées bien formées et effectuer une exécution symbolique pour capturer les contraintes sur les entrées. Les tests automatisés peuvent alors annuler une contrainte ou utiliser un solveur de contraintes pour dériver une nouvelle entrée et l'exécuter sur cette entrée. Lors de l'utilisation d'American fuzzy lop, une instrumentation au moment de la compilation est fournie, et l'instrumentation guide les algorithmes génétiques.
• Tests d'intrusion
  Une autre technique de test est le test d'intrusion. Le fuzz testing est une forme de test d'intrusion. Le test d'intrusion évalue la sécurité en essayant activement de trouver des vulnérabilités exploitables, ce qui est utile à la fois pour les attaquants et les défenseurs. Le test d'intrusion est utile à de nombreux niveaux différents (par exemple, pour tester des programmes, tester des applications, tester un réseau, tester un serveur).

IF VM_PRESENT() or DEBUGGER_PRESENT()
    Terminate()        // hide real intents
ELSE    
    Malicious_Behavior()    //real intent

Assurance de l'infrastructure Web

Le World Wide Web est un système organisationnel d'informations accessible via Internet. En d'autres termes, l'infrastructure du Web est fournie par la pile réseau TCP/IP. En particulier, examinez les rôles des différentes couches de la pile réseau TCP/IP d'Internet, les protocoles associés à chaque couche, et comment les paquets sont créés et échangés sur Internet. Il est important de savoir de quoi chaque couche est responsable et quels sont les protocoles prédominants à chaque couche. Enfin, il est recommandé d'expérimenter avec des analyseurs de protocole réseau existants pour étudier les paquets et la communication. Les principes de conception globaux de la pile réseau TCP/IP ont été essentiels pour créer un Internet capable d'évoluer avec les besoins changeants, mais les détails sont vraiment importants. Dans ce qui suit, nous allons approfondir des protocoles spécifiques pour comprendre les types d'attaques qui peuvent se produire au niveau de la couche réseau et comment s'en protéger.

Comme indiqué précédemment, le protocole DHCP peut créer des adresses IP dynamiquement et les associer aux hôtes lorsqu'ils se connectent au réseau. Le DNS mappe les noms de domaine aux adresses IP routables correspondantes (Figure 14.35).

Figure 14.35 Le protocole DHCP crée des adresses IP dynamiquement et les associe aux hôtes lorsqu'ils se connectent au réseau. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Étant donné que les requêtes DHCP sont initialement diffusées à tous les nœuds voisins, les attaquants sur le même sous-réseau peuvent entendre une nouvelle requête d'hôte et peuvent devancer le serveur DHCP réel pour remplacer le serveur DNS (c'est-à-dire rediriger toutes les recherches d'un hôte telles que "quelle adresse IP dois-je utiliser pour me connecter à google.com ?" vers une machine choisie par l'attaquant) ou la passerelle, où l'hôte envoie tout son trafic sortant afin que l'hôte n'ait pas à déterminer les routes par lui-même ; en faisant d'une machine choisie par l'attaquant la passerelle, l'attaquant serait en mesure d'agir en tant que MitM et d'obtenir l'accès à tout le trafic vers et depuis la machine de l'utilisateur. Alors, comment un utilisateur peut-il détecter une telle attaque ?

Le service DNS divise l'espace de noms de domaine en zones pour des raisons administratives. Les sous-domaines n'ont pas besoin d'être dans la même zone, ce qui permet au propriétaire d'une zone (par exemple, nyu.edu) de déléguer la responsabilité à une autre (par exemple, cs.nyu.edu). Le serveur de noms est le morceau de code qui répond aux requêtes de la forme "Quelle est l'adresse IP de cs.nyu.edu ?" Chaque zone doit exécuter au moins deux serveurs de noms. La mise en cache est essentielle au succès du service DNS. Malheureusement, elle est également essentielle aux attaques telles que l'empoisonnement de cache, qui consiste à remplir le cache d'une victime avec de fausses informations (Figure 14.36).

Figure 14.36 Un exemple d'empoisonnement de cache DNS consiste à remplir le cache DNS d'un serveur de noms local avec de fausses informations. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Dans le diagramme, le serveur de noms récursif est le serveur de noms qui effectue le gros du travail et émet des requêtes DNS au nom du résolveur client (c'est-à-dire l'hôte qui pose des requêtes DNS au nom du client) jusqu'à ce qu'une réponse faisant autorité soit renvoyée. Étant donné que le résolveur local a de nombreuses requêtes entrantes/sortantes à tout moment, il détermine quelle réponse correspond à quelles requêtes en utilisant un ID de requête (c'est-à-dire un champ de 16 bits dans l'en-tête DNS affiché comme 16322 à titre d'exemple dans le diagramme). Le demandeur définit l'ID de requête comme il le souhaite et le répondeur doit fournir la même valeur dans sa réponse. Pour qu'une attaque par empoisonnement de cache fonctionne, l'attaquant doit deviner l'ID de requête, le demander et agir à partir de là. Notez qu'une défense partielle consiste à randomiser les ID de requête, mais cela prend de l'espace, et l'attaquant peut émettre de nombreux ID de requête. Une fois que l'attaquant a deviné l'ID de requête, il doit deviner le numéro de port source, qui est généralement constant pour un serveur donné. Notez que si la réponse est déjà dans le cache, l'attaquant évitera d'émettre une requête en premier lieu.

La même approche d'empoisonnement de cache peut être utilisée pour empoisonner plus d'un enregistrement (Figure 14.37).

Figure 14.37 La même approche d'empoisonnement de cache peut être utilisée pour empoisonner plus d'un enregistrement mis en cache. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Notez que la randomisation de l'ID de requête n'est pas suffisante en soi car il n'y a que 16 bits d'entropie. Le port source doit donc également être randomisé car il n'y a aucune raison qu'il reste et il est possible d'obtenir 16 bits d'entropie supplémentaires de cette manière. Une autre solution consiste à utiliser les extensions de sécurité du système de noms de domaine. Si tout le monde l'a déployé et si vous connaissez les clés de la racine, alors DNSSEC empêche les réponses falsifiées. DNSSEC utilise une infrastructure à clé publique (PKI) pour sécuriser la communication entre les serveurs DNS dans les différentes zones, et la réponse faisant autorité est signée. Mais contrairement aux PKI, si un ou plusieurs serveurs de noms n'ont pas déployé DNSSEC (ce qui est le cas dans les déploiements incrémentaux), alors DNSSEC n'est pas très utile. Bien qu'il soit possible d'ignorer les réponses des serveurs de noms sans DNSSEC, cela améliorerait la sécurité mais empêcherait l'utilisateur de se connecter à un certain nombre d'hôtes.

Concentrons-nous maintenant sur les protocoles réseau et étudions les attaques et défenses TCP/IP possibles. En particulier, examinons la coucheréseau, qui fonctionne sur différentes technologies de liaison, relie plusieurs "sous-réseaux" pour fournir une connectivité Internet de bout en bout entre les nœuds, et fournit une adresse globale. Notez que si la couche de transport utilise le protocole TCP, cela n'entraînera qu'une livraison de données au mieux (c'est-à-dire pas de retransmissions). L'en-tête de paquet IPv4 utilisé par le protocole IP a une longueur de 20 B, et l'un des champs d'en-tête est l'adresse IP source. Rien dans le protocole IP n'impose que l'adresse IP source soit la vôtre. De plus, le protocole IP ne protège pas la charge utile ou les en-têtes. L'usurpation de source exploite cela (Figure 14.38).

Figure 14.38 L'usurpation de source exploite le fait que le protocole IP ne protège pas la charge utile ou les en-têtes. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

L'usurpation de source peut être utilisée pour envoyer de nombreux e-mails à partir d'un seul ordinateur (c'est-à-dire du spamming par e-mail). Le destinataire peut, en retour, bloquer les e-mails provenant d'une adresse IP donnée, mais l'attaquant pourrait usurper l'adresse IP source comme contre-mesure. Alors, un paquet que vous recevez a-t-il une source usurpée ?

Étant donné que l'Internet fonctionne via un routage basé sur la destination, la réponse à un message à source usurpée envoyé par un attaquant va à la source usurpée plutôt qu'à l'attaquant (c'est-à-dire pkt (source usurpée) -> destination : pkt -> source usurpée). Par conséquent, pour savoir si un paquet que vous recevez a une source usurpée, vous pouvez envoyer un paquet de défi à la source potentiellement usurpée (par exemple, un nombre aléatoire difficile à deviner, utilisé une seule fois [nonce]). Si le destinataire peut répondre au défi, il est probable que la source n'a pas été usurpée. Le problème avec cette approche est que vous devez le faire pour chaque paquet (c'est-à-dire que chaque paquet doit contenir quelque chose de difficile à deviner). Ceci est analogue aux ID de requête facilement prévisibles dans les attaques par empoisonnement de requête DNS qui ont facilité l'attaque de Kaminsky.

L'usurpation de source peut également être utilisée pour des attaques par déni de service (DoS). L'idée est de générer autant de trafic que possible pour engorger le réseau de la victime. Une défense facile consiste à bloquer tout le trafic provenant d'une source donnée près de la périphérie de votre réseau. Une contre-mesure facile consiste à usurper l'adresse source. Les défis ne seront pas utiles ici car les dégâts auront été faits au moment où les paquets atteindront le cœur de votre réseau. Idéalement, vous devriez donc détecter une telle usurpation près de la source, et le filtrage de sortie fait exactement cela. Le point (routeur/commutateur) où le trafic entre dans votre réseau est le point d'entrée, et le point (routeur/commutateur) où le trafic quitte votre réseau est le point de sortie. Bien que vous ne sachiez pas qui possède toutes les adresses IP dans le monde entier, vous savez qui, dans votre réseau, obtient quelles adresses IP. Par conséquent, votre point de sortie peut rejeter tout paquet dont l'adresse IP source ne correspond pas à l'adresse IP que votre réseau a attribuée à cette machine. Cette approche de filtrage de sortie n'est pas souvent déployée car votre point de sortie supporte les coûts mais votre réseau n'en tire aucun avantage.

Les méthodes de défense suggérées précédemment pour contrer l'écoute clandestine/la falsification des en-têtes IP ne sont clairement pas infaillibles. Une meilleure méthode de protection contre le fait qu'aucune sécurité n'est intégrée à IP consiste à sécuriser profondément IP sur IP. Cela se fait en utilisant un réseau privé virtuel (VPN). L'objectif d'un VPN est de permettre à un client de se connecter à un réseau de confiance depuis un réseau non fiable. Par exemple, vous pourriez utiliser un VPN pour vous connecter au réseau de votre entreprise pour accéder aux fichiers de paie tout en visitant le bureau d'un concurrent. Dans ce cas, un client et un serveur VPN créeraient un canal chiffré/authentifié de bout en bout, comme illustré dans Figure 14.39. Une façon prédominante d'y parvenir est d'utiliser le protocole de sécurité Internet pour sécuriser les datagrammes IP (au lieu d'utiliser TLS ou un shell sécurisé au niveau de la couche application). Cela a été considéré comme une bonne idée vers 1992-1993 car cela sécuriserait tout le trafic (pas seulement TCP/UDP) et sécuriserait automatiquement les applications (sans nécessiter de modifications). Il fournit également un pare-feu/un contrôle d'accès intégré. Les premières normes proposées ont été publiées en 1988, et une révision (c'est-à-dire Internet Key Exchange version 2) a été approuvée en 2005.

Figure 14.39 Un client et un serveur VPN peuvent être utilisés pour créer un canal chiffré/authentifié de bout en bout. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

L'Internet Key Exchange a abordé les problèmes d'anonymat et la prévention des DoS. Il y a eu de nombreuses implémentations d'IPSec, et presque tous les déploiements se font dans des configurations VPN. Les gens ont fini par passer à SSL/VPN, mais ce n'était pas l'utilisation prévue de SSL. IPSec est aujourd'hui considéré comme un semi-échec car il est complexe, difficile à utiliser et présente des défauts de conception. IPsec n'a pas réussi à définir le bon modèle d'utilisation, mais SSL/TLS et SSH (discutés plus loin dans cette sous-section) l'ont fait.

IPSec fonctionne selon plusieurs modes différents :

• Mode transport : Chiffre la charge utile mais pas les en-têtes
• Mode tunnel : Chiffre la charge utile et les en-têtes

Les formats de paquets correspondants sont illustrés dans Figure 14.40.

Figure 14.40 IPsec utilise des formats de paquets spécifiques pour le mode transport et le mode tunnel. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Pour que le routage fonctionne lorsque le mode tunnel chiffre les en-têtes, IPSec chiffre l'intégralité du paquet IP et en fait la charge utile d'un autre paquet IP.

Figure 14.41 illustre l'utilisation d'IPSec en mode tunnel. Dans ce cas, le serveur VPN déchiffre puis envoie la charge utile (elle-même un paquet IP complet) comme s'il venait de la recevoir du réseau. Du point de vue du client/serveur, il semble que le client soit physiquement connecté au réseau.

Figure 14.41 En mode tunnel IPsec, le serveur VPN déchiffre puis envoie la charge utile (elle-même un paquet IP complet) comme s'il venait de la recevoir du réseau. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Concentrons-nous maintenant sur la couche de transport de la pile TCP/IP et étudions les attaques et défenses TCP/IP possibles. Les couches de transport assurent la communication de bout en bout entre les processus. Elles fournissent différents services, notamment UDP et TCP (flux d'octets fiable). Fiable signifie qu'il suit les données correctement reçues et retransmet les paquets si nécessaire. Étant donné une livraison au mieux, l'objectif est d'assurer la fiabilité. Tous les paquets sont livrés aux applications dans un ordre non modifié (probabilité raisonnablement élevée) et TCP doit détecter et retransmettre de manière robuste les données corrompues ou perdues. La deuxième tâche de TCP est le contrôle de flux et de congestion. L'idée est d'essayer d'utiliser autant de réseau que possible de manière sûre (sans affecter négativement les performances des autres) et efficace (en utilisant la capacité du réseau). La solution TCP consiste à adapter dynamiquement la vitesse d'envoi des paquets en fonction de la capacité du chemin réseau. De plus, lorsqu'un ACK ne revient pas, le réseau peut être au-delà de sa capacité et ralentir. TCP est un protocole orienté connexion, et il existe divers indicateurs TCP dans l'en-tête TCP qui sont utilisés pour gérer les connexions comme indiqué :

• SYN : Utilisé pour établir une connexion
• ACK : Accusés de réception pour les données et les paquets de "contrôle"
• FIN : Utilisé pour fermer une connexion en utilisant FIN et FIN+ACK
• RST : Utilisé pour la notification de fermeture (dit "supprimez tout votre état local, car je ne sais pas de quoi vous parlez")

Diverses attaques sont connues pour exploiter la vulnérabilité de la couche de transport. Par exemple, l'inondation SYN exploite une vulnérabilité dans la poignée de main en trois étapes de l'établissement de connexion TCP, comme illustré dans Figure 14.42.

Figure 14.42 L'inondation SYN exploite une vulnérabilité dans la poignée de main en trois étapes de l'établissement de connexion TCP. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Si B ne reçoit pas d'accusé de réception, il conservera cet état local et retransmettra SYN+ACK jusqu'à ce qu'il reçoive une réponse ou que le délai d'attente expire (jusqu'à 63 s). Il est facile de détecter de nombreuses poignées de main incomplètes provenant d'une seule adresse IP, puis d'usurper l'adresse IP source comme illustré dans Figure 14.43 (il s'agit simplement d'un champ dans un en-tête, comme décrit précédemment, qui peut être défini comme l'attaquant "C" le souhaite). Un problème possible est que l'hôte qui possède cette adresse IP usurpée puisse répondre au SYN+ACK par un RST, supprimant l'état local de la victime. Par conséquent, un attaquant devrait usurper l'adresse IP d'un hôte dont il sait qu'il ne répondra pas.

Figure 14.43 Cet exemple d'usurpation d'adresse IP illustre comment détecter de nombreuses poignées de main incomplètes à partir d'une seule adresse IP, puis usurper l'adresse IP source. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Une défense contre l'inondation SYN consiste à utiliser des cookies SYN, comme illustré dans Figure 14.44.

Figure 14.44 L'utilisation de cookies SYN offre une défense contre l'inondation SYN. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Le format du cookie SYN est illustré dans Figure 14.45.

Figure 14.45 Les cookies SYN utilisent un format spécifique. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Les attaques par injection exploitent la présence d'un nœud sur le chemin entre la source et la destination. Dans ce cas, l'injection de paquets avec le numéro de séquence correct est triviale. Si le nœud n'est pas sur le chemin, il devrait deviner le numéro de séquence, ce qui est difficile. Les numéros de séquence initiaux étaient déterministes, et il était facile de semer le chaos en envoyant des RST, en injectant des paquets de données dans une connexion existante (c'est-à-dire des attaques de veto TCP), ou en initiant et en utilisant une connexion entière sans jamais entendre l'autre extrémité. Figure 14.46 illustre un type d'attaque connu sous le nom d'attaque Mitnick.

Figure 14.46 Une attaque Mitnick usurpe l'adresse IP d'un serveur de confiance pour obtenir l'accès au serveur X-terminal auquel il se connecte. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Une défense typique consiste à s'assurer que le numéro de séquence initial est difficile à prédire.

Les attaques OPT-ACK exploitent le fait que TCP utilise les ACK non seulement pour la fiabilité mais aussi pour le contrôle de congestion (c'est-à-dire, plus il y a d'ACK qui reviennent, plus il peut envoyer rapidement), comme illustré dans Figure 14.47.

Figure 14.47 Une attaque OPT-ACK exploite le fait que TCP utilise les ACK non seulement pour la fiabilité mais aussi pour le contrôle de congestion. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Un attaquant peut exploiter cela comme illustré dans Figure 14.48.

Figure 14.48 Une exploitation OPT-ACK convainc TCP d'envoyer des paquets rapidement, ce qui entraîne une attaque DoS sur le réseau. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0 ; crédit : reproduit avec l'autorisation de Dave Levin)

Le schéma d'attaque réel est illustré dans Figure 14.49.

Figure 14.49 Le schéma d'attaque OPT-ACK entraîne la perte de paquets tandis que TCP est trompé en pensant que les paquets ont été accusés de réception. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Le gros problème avec cette attaque est son facteur d'amplification. Un attaquant envoie de nombreux octets de données, ce qui amène la victime à en envoyer beaucoup plus en réponse. Il existe des exemples de telles attaques sur NTP et DNSSEC. L'attaque est amplifiée dans TCP en raison de son support des ACK cumulatifs (c'est-à-dire, "ACK x" signifie "J'ai vu tous les octets jusqu'à x, mais pas x inclus"). Figure 14.50 illustre le nombre maximal d'octets qui peuvent être envoyés par une victime par ACK.

Figure 14.50 Cette illustration montre le nombre maximal d'octets par ACK. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Figure 14.51 montre le nombre maximal d'ACK qu'un attaquant peut envoyer par seconde.

Figure 14.51 Cette illustration montre le nombre maximal d'ACK envoyés par l'attaquant. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Par conséquent, l'ampleur des dégâts est la valeur de la taille maximale de la fenêtre et du MSS (par exemple, taille maximale de la fenêtre par défaut : 65 536 et MSS par défaut : 536). Dans ce cas :

• Facteur d'amplification par défaut : 65536 * (1/536 + 1/54) ~ 1336x
• La mise à l'échelle de la fenêtre permet d'augmenter cela d'un facteur de 2^14
• Facteur d'amplification de la mise à l'échelle de la fenêtre : ~1336 * 2^14 ~ 22M
• En utilisant un MSS minimum de 88 : ~ 32M

Un défi consiste à trouver une solution pour se défendre contre OPT-ACK d'une manière qui soit toujours compatible avec les implémentations existantes de TCP. Notez également qu'un objectif essentiel en réseau est le déploiement incrémental. Idéalement, nous devrions pouvoir bénéficier d'un système/modification même lorsqu'un sous-ensemble d'hôtes le déploie.

Concentrons-nous maintenant sur la couche application de la pile TCP/IP et étudions les attaques et défenses TCP/IP possibles. Le protocole SSL était à l'origine un protocole propriétaire de Netscape qui ciblait les applications de commerce électronique (c'est-à-dire ce que les gens pensaient que le Web était en 1994). L'objectif était de répondre à des résultats tels que "envoyer ma carte de crédit à Amazon en toute sécurité". Le principe de base était d'authentifier le serveur et de laisser le client accéder au serveur sans authentification. SSLv1 a été conçu par Kipp Hickman et présentait de graves failles de sécurité. Il a corrigé certaines des failles dans SSLv2, qui avait encore des problèmes de sécurité mais était largement déployé. SSLv3 a corrigé ces problèmes. Le protocole TLS 1.0 était la première version standardisée de SSL avec quelques améliorations pour la dérivation de clés (voir RFC 2246 de ietf.org). TLS 1.1 a corrigé certaines failles de sécurité, et TLS 1.2 a ajouté plus de flexibilité dans l'utilisation des fonctions de hachage. TLS 1.3 a apporté des changements significatifs (par exemple, pas d'échange de clés RSA pour la confidentialité persistante, modes de chiffrement authentifiés, pas de poignées de main RTT). Comme expliqué précédemment, une CA de confiance peut garantir qu'une certaine clé publique appartient à un site particulier et émettre un certificat TLS qui respecte le format x.509.

Les applications Web utilisent HTTP sur SSL/TLS (HTTPS), auquel cas le client sait que le serveur attend HTTPS (car il est spécifié dans l'URL et pris en charge sur un port séparé sur le serveur). De plus, le certificat du serveur contient son nom de domaine. HTTP est sans état, et la durée de vie d'une session HTTP est la suivante :

• Le client se connecte au serveur.
• Le client émet une requête.
• Le serveur répond.
• Le client émet une requête pour quelque chose dans la réponse.
• L'interaction se poursuit jusqu'à ce que le client ait reçu toutes les informations dont il a besoin.
• Le client se déconnecte.

Étant donné que les opérations asymétriques (opérations de clé privée) sont coûteuses (et que HTTPS a tendance à impliquer de nombreuses connexions SSL/TCP), la mise en cache est rentable. Chaque poignée de main établit une session, et les clients peuvent reprendre la session avec le même matériel de clé, en sautant l'échange de clés. Si le client et les serveurs ne connaissent pas leurs capacités mutuelles, ils peuvent les découvrir et passer automatiquement à TLS. Cela peut cependant permettre des attaques de rétrogradation.

Les attaques DoS sur SSL/TLS reposent sur le fait que la connexion SSL/TLS nécessite une poignée de main TCP, et les connexions TCP sont faciles à attaquer avec un DoS. La protection contre ces types d'attaques doit se situer à une couche inférieure et est fournie par Datagram TLS. DTLS est une légère modification de TLS qui offre la fiabilité pour la poignée de main et garantit que les enregistrements de données sont indépendants.

Tatu Ylonen a initialement conçu le protocole Secure Shell (SSH), qui remplace rsh. C'est maintenant l'outil standard pour la connexion à distance sécurisée, et il fournit de nombreux mécanismes d'authentification, tels que X distant, le transfert de fichiers et le transfert de port. Le protocole de transport utilisé par SSH ressemble beaucoup à TLS. SSL n'utilise pas de certificats ; le serveur a juste une clé publique brute et il fournit la clé lorsque le client se connecte. Le client stocke la clé du serveur lors de la première connexion. Tout changement de clé entraîne une erreur. La clé peut être authentifiée hors bande (c'est-à-dire que l'opérateur du serveur communique l'empreinte/le hachage de la clé au client par téléphone ; seuls les personnes les plus concernées le font). L'authentification par "saut de la foi" de SSH a été considérée comme extrême au début, mais est maintenant considérée comme astucieuse. L'authentification du client SSH nécessite d'abord l'authentification du serveur, puis authentifie le client en utilisant divers mécanismes négociés (par exemple, mot de passe brut, défi-réponse, clé publique, GSS-API, Kerberos). SSH fournit des fonctionnalités de transfert de port/tunneling. Le transfert de port SSH redirige le trafic réseau vers un port/adresse IP particulier afin qu'un hôte distant soit directement accessible par les applications sur l'hôte local. La destination peut être sur le serveur SSH distant, ou ce serveur peut être configuré pour transférer vers un autre hôte distant. Les tunnels SSH sont des outils puissants pour les administrateurs informatiques et les acteurs malveillants car ils peuvent transiter un pare-feu d'entreprise sans être détectés. Par conséquent, des outils sont disponibles pour empêcher l'utilisation non autorisée des tunnels SSH à travers un pare-feu d'entreprise. Figure 14.52 illustre comment une connexion à distance X11 peut être établie en utilisant SSH.

Figure 14.52 Avec une connexion SSH à distance X11, le serveur doit simplement "setenv DISPLAY localhost: XXXX" et les applications fonctionnent automatiquement. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Enfin, SSH est rétrocompatible avec rsh, de sorte que d'autres applications peuvent être sécurisées à distance sans transfert de port. C'est également utile lorsque les applications nécessitent un accès à distance non sécurisé.

Les divers protocoles de couche application que nous avons discutés sont sujets à une variété d'attaques, y compris les vecteurs d'attaque, les attaques de conception de site, les attaques basées sur l'interface utilisateur, les attaques PKI, les attaques d'implémentation, Goto fail, heartbleed, l'attaque BERserk, Logjam, Cloudbleed et l'interception HTTP côté client.

Les vecteurs d'attaque sont conçus pour attaquer l'autorité de certification la plus faible. Ils attaquent les implémentations de navigateurs. Ils peuvent également trouver et exploiter un bogue de bibliothèque de génération de clés qui conduit l'attaquant à découvrir toutes les clés privées émises par cette autorité. Ils ont également attaqué les primitives cryptographiques, bien que cela ait été plus difficile à réaliser.

Les attaques SSLStrip sont des exemples d'attaques qui ciblent la conception de sites en passant par le contenu sans HTTPS. La défense consiste à utiliser HTTPS par défaut pour tous les sites Web. Vous pouvez également utiliser HSTS, qui est appliqué par les navigateurs ; l'en-tête indique de toujours s'attendre à HTTPS. HTTPS partout peut également être forcé à l'aide d'une extension de navigateur. Certaines attaques de conception de site utilisent des attaques de contenu mixte. Dans ce cas, une page se charge via HTTPS mais contient du contenu via HTTP. Un attaquant actif peut altérer le contenu HTTP pour détourner la session. La défense consiste à émettre des avertissements de navigateur (par exemple, "Cette page contient du contenu non sécurisé"), mais l'utilisation de ces avertissements est incohérente et les avertissements sont souvent ignorés.

Les attaques basées sur l'interface utilisateur exploitent des certificats invalides (c'est-à-dire expirés, URL mal identifiée, CA inconnue comme un certificat auto-signé). La défense consiste à émettre des avertissements de navigateur et à exiger des utilisateurs qu'ils passent par une page anti-utilisabilité pour continuer. Un autre type d'attaque basée sur l'interface utilisateur est une attaque "image dans l'image" qui usurpe l'interface utilisateur (c'est-à-dire que la page de l'attaquant dessine une fausse fenêtre de navigateur avec une icône de verrouillage). Dans ce cas, la défense consiste à créer une image individualisée.

Les attaques PKI compromettent les CA. Il y a eu un exemple d'une telle attaque en 2011 contre une CA néerlandaise nommée DigiNotar. Elle a émis un certificat *.google.com à un attaquant qui l'a ensuite utilisé pour orchestrer des attaques MitM en Iran. Personne n'a remarqué l'attaque avant que quelqu'un ne trouve le certificat dans la nature. DigiNotar a ensuite admis que des dizaines de certificats frauduleux avaient été créés. Google, Microsoft, Apple et Mozilla ont tous révoqué le certificat racine DigiNotar. Le gouvernement néerlandais a repris DigiNotar, et l'entreprise a ensuite fait faillite et a fermé. En général, MD5/SHA1 est connu pour être cassé et peut générer des collisions. En 2008, des chercheurs ont montré qu'ils pouvaient créer un certificat CA malveillant en utilisant une collision MD5. L'attaque consistait à faire entrer en collision les messages A et B, avec le même hachage MD5 comme suit :

• A: Certificat de site : "cn=attack.com, pubkey=....”
• B: Certificat CA délégué : "pubkey=.... est autorisé à signer des certificats pour *”
• Obtenir que la CA signe A -- La signature est Sign(MD5)
• La signature est également valide pour B (même hachage)
• L'attaquant est maintenant une CA !
• Créer un certificat pour n'importe quel site, les navigateurs l'accepteront

Les certificats CA MD5 existent toujours, mais les CA ont cessé de signer des certificats avec eux. SHA-1 ne devrait pas non plus être utilisé.

Il existe de nombreux autres types d'attaques :

• Goto fail (février 2014) était un bogue SSL d'Apple qui a entraîné le saut de la vérification des certificats pendant près d'un an.
• Heartbleed était un bogue OpenSSL qui a divulgué des données, y compris potentiellement la clé privée !
• La vulnérabilité Mozilla BERserk était un bogue dans la vérification des signatures de certificats qui permettait l'usurpation de certificats.
• Logjam a exploité une vulnérabilité TLS pour des attaques de "rétrogradation" de type homme du milieu.
• Cloudbleed, l'un des "réseaux de diffusion de contenu" les plus populaires, agit comme point de terminaison SSL pour de nombreux serveurs ; une attaque par débordement de tampon l'a fait fuir des données HTTPS.
• L'interception HTTP côté client exploite le fait que la plupart des logiciels antivirus interceptent votre HTTPS, générant de mauvaises implémentations et introduisant de nouvelles vulnérabilités.

Assurance des cadriciels d'applications Web/mobiles

Les cadriciels d'applications web/mobiles les plus typiques sont les serveurs web et les navigateurs web. D'autres cadriciels d'applications web/mobiles (par exemple, les serveurs d'applications, les suites de gestion des processus d'affaires) fonctionnent à l'aide de navigateurs web et de serveurs web étendus et utilisent les mêmes mécanismes de sécurité. Cette sous-section se concentrera uniquement sur les serveurs web et les navigateurs web. Divers types d'attaques affectent les informations et les interactions web, y compris l'injection SQL, le cross-site scripting (XSS), le parcours de chemin (répertoire), la falsification de requêtes intersites, l'inclusion de fichiers à distance, l'hameçonnage, le clickjacking, les attaques d'authentification/autorisation, les erreurs de tampon, les attaques de navigateur web, la fuite/divulgation d'informations et les attaques de serveur web.

Voici plusieurs risques de sécurité contre lesquels nous essayons de protéger les serveurs web :

• Risque 1 : Nous voulons que les données stockées sur un serveur web soient protégées contre tout accès non autorisé.
• Risque 2 : Nous ne voulons pas que des sites malveillants puissent détruire des fichiers/programmes sur les ordinateurs des utilisateurs.
• Risque 3 : Nous ne voulons pas qu'un site malveillant puisse espionner ou altérer des informations ou des interactions avec d'autres sites web.

La Federal Communications Commission a identifié des conseils en matière de cybersécurité pour aider les organisations à se protéger contre les cybermenaces lors de l'utilisation d'Internet. Ceux-ci incluent38 :

• S'assurer que les employés sont formés à la cybersécurité, y compris aux principes de sécurité de l'organisation.
• Maintenir le système à jour avec les derniers logiciels de sécurité et exécuter fréquemment un logiciel antivirus.
• Installer et maintenir un pare-feu, qui est un ensemble de programmes conçus pour empêcher les pirates et autres utilisateurs non autorisés d'accéder à un système.
• S'assurer que les appareils mobiles et les ordinateurs portables sont inclus dans le plan de sécurité et sécuriser tous ces appareils.
• Sauvegarder les fichiers et données importants et stocker les informations sauvegardées séparément.
• S'assurer que tous les employés disposent de mots de passe et d'autres identifiants nécessaires pour accéder au système et fournir un accès au besoin.
• S'assurer que les réseaux Wi-Fi sont cachés et sécurisés par chiffrement.

Les lignes directrices de conception et de mise en œuvre suivantes peuvent être consultées en ligne via une recherche par navigateur :

• Initiatives de cybersécurité OMG (et normes, lignes directrices, bonnes pratiques et autres ressources connexes)
• Normes de cybersécurité NIST (en particulier NIST SP 800-53, SP 800-171, CSF, série SP 1800)
• Autres cadriciels et normes mondiaux de sécurité informatique : série ISO 27000, COBIT, contrôles CIS, HITRUST Common Security Framework, GDPR, COSO
• Normes de sécurité informatique de l'industrie : PCI, HIPAA, PCI DSS, Sarbanes-Oxley, GLBA
• CyBok
• SAFECode
• Manuel de méthodologie de test de sécurité open source
• Open Web Application Security Project (OWASP)
• Classification des menaces du Web Application Security Consortium
• Norme d'exécution des tests d'intrusion
• Cadriciel d'évaluation de la sécurité des systèmes d'information

Assurance de l'infrastructure infonuagique

Pour atteindre les niveaux de sécurité que les utilisateurs finaux connaissent sur site, les FSI doivent investir de manière appropriée pour fournir, prouver et assurer des niveaux de sécurité adéquats au fil du temps. Cela nécessite la construction d'architectures de sécurité et de confiance qui peuvent garantir que les applications et les données de chaque utilisateur final sont isolées et sécurisées par rapport à celles des autres. Avant de déplacer des systèmes d'information critiques vers l'infonuage, les utilisateurs finaux exigent une cybersécurité robuste, une assurance cybersécurité digne de confiance et une gouvernance de l'infonuage comme suit :

• Une sécurité robuste exige de dépasser une approche traditionnelle basée sur le périmètre pour adopter une architecture de sécurité infonuagique multicouche et une approche qui assure l'isolation appropriée des données, même dans un nuage partagé et multi-locataire. Cela inclut la protection du contenu à différentes couches de l'infrastructure infonuagique, telles que le stockage, l'hyperviseur, la machine virtuelle et la base de données. Cela nécessite également des mécanismes pour assurer la confidentialité et le contrôle d'accès. Ceux-ci peuvent inclure le chiffrement, l'obscurcissement et la gestion des clés, ainsi que l'isolation et le confinement, une gestion robuste des journaux et une infrastructure d'audit. L'architecture de sécurité fournit l'isolation, la confidentialité et le contrôle d'accès nécessaires pour protéger les données et les applications des utilisateurs finaux.
• Une assurance cybersécurité digne de confiance exige que les utilisateurs finaux aient confiance en l'intégrité de l'environnement infonuagique complet. Cela va des centres de données physiques au matériel et aux logiciels, ainsi qu'aux personnes et aux processus employés par le FSI. Cela nécessite d'établir une architecture de confiance basée sur des preuves et un contrôle de l'environnement infonuagique fourni par le FSI. Cela exige que le FSI fournisse des capacités de surveillance et de reporting adéquates pour assurer à l'utilisateur final la transparence concernant les vulnérabilités et les événements de sécurité. Cela devrait inclure des pistes d'audit qui aident l'utilisateur final à répondre aux exigences internes ou externes en matière de sécurité prouvable. Un FSI devrait également fournir des notifications et des alertes automatisées qui prennent en charge les protocoles de gestion des problèmes ou des incidents existants de l'utilisateur final afin qu'il puisse gérer son profil de sécurité total le plus facilement possible. Tous ces éléments contribuent collectivement à assurer à l'utilisateur final la qualité opérationnelle et la sécurité du FSI.
• La gouvernance de l'infonuage exige que le FSI offre des utilitaires qui permettent à l'utilisateur final de surveiller son environnement pour la sécurité et d'autres indicateurs de performance clés tels que les performances et la fiabilité presque aussi bien qu'il le ferait dans son propre environnement sur site (ou centre de données).

Assurance des services infonuagiques

Étant donné que les utilisateurs finaux exploitent divers types de services tels que l'infrastructure en tant que service (IaaS) par rapport à la plateforme en tant que service (PaaS) pour créer des solutions dans l'infonuage, les FSI et les utilisateurs finaux de l'infonuage partagent des responsabilités uniques et superposées pour assurer la sécurité des services et des données sensibles stockées dans les nuages publics. Les considérations de responsabilité partagée incluent la détection des menaces, la réponse aux incidents et la correction/mise à jour. Un exemple de service PaaS fourni par les plateformes infonuagiques aujourd'hui est l'IoT PaaS.

Comme indiqué précédemment, les plateformes infonuagiques IoT sont confrontées à de nombreux défis qui affectent la qualité de l'assurance de la sécurité et de l'intégrité/confidentialité TRM. Les appareils et les données IoT sont vulnérables à diverses menaces, telles que les cyberattaques, les violations de données, les accès non autorisés et la manipulation malveillante. Ces menaces peuvent compromettre la fonctionnalité, l'intégrité et la confidentialité des systèmes IoT, ainsi qu'exposer des informations sensibles et personnelles des clients et des utilisateurs. Les plateformes infonuagiques IoT doivent également adhérer aux réglementations et normes en évolution qui régissent la collecte, le stockage et l'utilisation des données IoT, telles que le Règlement général sur la protection des données (GDPR) et le California Consumer Privacy Act. C'est pourquoi il est important de disposer d'architectures de sécurité et de confiance infonuagiques ainsi que d'une gouvernance infonuagique qui fournissent des mesures de sécurité et de confidentialité robustes, telles que le chiffrement, l'authentification, l'autorisation, la surveillance et la conformité, qui peuvent protéger les appareils et les données IoT de bout en bout.

Un autre exemple de service PaaS fourni par les plateformes infonuagiques aujourd'hui est l'analytique des mégadonnées PaaS. Comme indiqué précédemment et du point de vue de la qualité de l'assurance/sécurité/confidentialité TRM, la sécurité est clairement l'une des principales préoccupations de l'analytique des mégadonnées. Le piratage et diverses attaques contre l'infrastructure infonuagique se produisent et peuvent affecter plusieurs clients même si un seul site est attaqué. Pour optimiser la compréhension des mégadonnées, les organisations doivent intégrer des parties de leurs données sensibles dans les données plus grandes. Pour ce faire, les entreprises doivent établir des politiques de sécurité auto-configurables. Ces politiques doivent exploiter les relations de confiance existantes et promouvoir le partage de données et de ressources au sein des organisations, tout en garantissant que l'analytique des données est optimisée et non limitée par de telles politiques. C'est pourquoi il est important de disposer d'architectures de sécurité et de confiance infonuagiques ainsi que d'une gouvernance infonuagique pour atténuer les risques en utilisant des applications de sécurité, des systèmes de fichiers chiffrés, des logiciels de perte de données et en achetant du matériel de sécurité pour suivre les comportements inhabituels sur les serveurs.

Un dernier exemple de service PaaS fourni par les plateformes infonuagiques aujourd'hui est le PaaS de robotique infonuagique. Du point de vue de la sécurité, lorsque les robots sont connectés à l'infonuage, ils sont susceptibles d'être piratés et de subir des cyberattaques. Cela peut constituer un risque sérieux à la fois pour la sécurité des robots et la confidentialité des données qu'ils collectent. C'est encore une fois pourquoi il est important de disposer d'architectures de sécurité et de confiance infonuagiques ainsi que d'une gouvernance infonuagique pour aider les entreprises à développer des robots connectés à l'infonuage et à investir dans des mesures de sécurité infonuagique robustes.

Assurance des cadriciels d'applications infonuagiques

Les cadriciels d'applications infonuagiques sont entièrement gérés par les FSI ou conçus pour exploiter les services IaaS/PaaS sur des plateformes infonuagiques sécurisées. Un serveur infonuagique peut remplacer les cadriciels d'applications traditionnels au prix de la migration des applications traditionnelles qui utilisaient ces cadriciels vers l'infonuage, ce qui est une proposition coûteuse et chronophage. Pour cette raison, les cadriciels d'applications des grandes technologies sont maintenant disponibles sur des plateformes infonuagiques sécurisées (par exemple, IBM WebSphere Hybrid Edition, Oracle WebLogic Server pour Oracle Cloud Infrastructure). Les systèmes/cadriciels de gestion de bases de données traditionnels sont plus faciles à migrer vers l'infonuage. Par exemple, les systèmes de gestion de bases de données traditionnels tels que MySQL, PostgresSQL ou SQL Server peuvent être migrés vers Google Cloud SQL. Google fournit également des systèmes de bases de données NoSQL basés sur l'infonuage (par exemple, la base de données de documents Firestone, la base de données clé-valeur Bigtable, la base de données en mémoire Memorystore). Des systèmes/cadriciels de bases de données infonuagiques similaires sont disponibles sur Microsoft Azure (par exemple, la base de données Azure SQL) et d'autres plateformes infonuagiques. Le support infonuagique pour les cadriciels d'applications ne se limite pas aux systèmes/cadriciels de bases de données. Par exemple, Azure App Service est un cadriciel de plateforme infonuagique qui peut être utilisé pour héberger en toute sécurité des applications web, des API REST et des applications mobiles. Plus récemment, VMware a développé un serveur d'applications infonuagiques appelé Tanzu, anciennement Cloud-Foundry, qui fonctionne entièrement sur l'infonuage et exploite les dernières technologies de gestion de conteneurs et de cybersécurité infonuagique. IBM Bluemix est également dérivé de Cloud-Foundry. De plus, toutes les plateformes de médias sociaux peuvent être considérées comme des exemples de cadriciels d'applications infonuagiques sécurisés. Comme il n'existe pas de normes pour l'utilisation/l'implémentation de cadriciels d'applications sécurisés sur l'infonuage, les utilisateurs finaux doivent consulter les sites web des différents FSI et se tenir informés de la disponibilité de ces cadriciels d'applications.

Assurance des applications infonuagiques

Les applications infonuagiques sont généralement implémentées sur des serveurs infonuagiques, et les développeurs tirent pleinement parti des architectures de sécurité/confiance infonuagiques établies ainsi que des processus de gouvernance infonuagique. Les grandes organisations technologiques fournissent généralement les meilleures pratiques, modèles et motifs de sécurité pour faciliter la création d'applications infonuagiques sécurisées sur leur propre plateforme.

Assurance de l'information infonuagique

Dans l'informatique en nuage, une grande partie des bases de données volumineuses et critiques sont sous le contrôle des FSI. Ces ressources sont situées loin de l'emplacement physique de l'utilisateur final, et souvent dans des emplacements physiques inconnus de l'utilisateur final. La possibilité, voire la probabilité, que les données soient stockées dans d'autres régions et pays, exige également de respecter les exigences légales et réglementaires de ces régions en matière de protection des données. Tout cela rend plus difficile la création de contrôles fiables pour la surveillance, la gouvernance et l'audit de l'environnement FSI. Par conséquent, comme expliqué précédemment, il est nécessaire de développer des architectures de sécurité/confiance infonuagiques ainsi que des processus de gouvernance infonuagique avant de développer des systèmes d'information sur l'infonuage ou de migrer des systèmes d'information traditionnels/hérités et leurs données vers l'infonuage.

Méthodologies d'assurance infonuagique

Diverses organisations fournissent les meilleures pratiques de sécurité infonuagique et des méthodologies d'évaluation de la cybersécurité infonuagique. En particulier, la Cloud Security Alliance et l'Agence de l'Union européenne pour la cybersécurité promeuvent les meilleures pratiques développées pour fournir une assurance de sécurité dans l'informatique en nuage. Le guide de sécurité de la CSA fournit quatorze domaines de meilleures pratiques de sécurité infonuagique. Il est basé sur des recherches dédiées et la participation du public, incorporant les avancées dans l'infonuage, la sécurité et les technologies de support. La Security Assurance Methodology est un cadre d'assurance de sécurité développé par le 3rd Generation Partnership Project (3GPP) spécifiquement pour les produits réseau utilisés dans les communications mobiles. Les grandes organisations technologiques fournissent généralement des méthodologies d'évaluation des risques adaptées à l'utilisation de leur plateforme infonuagique. Microsoft, par exemple, publie un guide d'évaluation des risques pour Azure. D'autres FSI fournissent des services similaires.

Crise du matériel

En octobre 2020, un incendie d'entrepôt a gravement endommagé l'usine de semi-conducteurs Asahi Kasei Microdevices à Miyazaki, au Japon. À l'époque, c'était l'un des deux fabricants de RAM dans le monde. La crise mondiale de la mémoire informatique a rapidement commencé peu après cette catastrophe. Les fabricants de matériel ont dû ralentir la production d'ordinateurs car la mémoire n'était pas disponible pour la production, et le coût de la mémoire existante a augmenté. Les autres usines de fabrication de puces du Japon n'ont pas pu répondre à la demande mondiale. Aujourd'hui, trois usines de fabrication représentent plus de 90 % de la production mondiale de RAM. Il semble que le monde n'ait pas appris sa leçon et n'ait pas diversifié la production de cette précieuse ressource.

L'autre aspect de cette histoire est que les avancées logicielles se sont également arrêtées. Les nouveaux progiciels sont généralement développés pour incorporer de nouvelles fonctionnalités technologiques. Si la fabrication de nouveaux ordinateurs a ralenti, les nouveaux progiciels innovants ont également ralenti. Ce n'était pas le cas pour les technologies infonuagiques. Étant donné que les ressources sont distribuées et que le matériel n'est pas aussi essentiel, l'environnement infonuagique continue de prospérer, et il n'y a eu qu'une augmentation de l'utilisation de l'infonuage depuis 2020.

Assurance des plateformes d'écosystèmes intelligents

Comme indiqué précédemment, les écosystèmes intelligents de l'Industrie 4.0 combinent diverses plateformes/services (par exemple, modélisation 3D, RA/RV, Edge Computing, chaîne de blocs, IA/ML et impression 3D/4D) et sont généralement déployés aujourd'hui sur un environnement de nuage hybride/chaîne de blocs. Par exemple, ils peuvent utiliser des plateformes/services IA/ML pour prendre en charge le rendu et la gestion de modèles réalistes d'un monde 3D ou de jumeaux numériques. Les diverses plateformes/services fonctionnent au sein de plateformes de nuage/chaîne de blocs sécurisées qui sont gérées à l'aide d'architectures de sécurité/confiance de nuage/chaîne de blocs établies ainsi que de processus de gouvernance de nuage. Étant donné que les plateformes/services peuvent être assemblés en applications composites en combinant des offres de plusieurs plateformes infonuagiques, il est nécessaire de prendre en compte les mécanismes de cybersécurité discutés dans Assurance des cadriciels d'applications infonuagiques afin de comprendre comment sécuriser au mieux les applications composites infonuagiques. Dans cette sous-section, nous discutons brièvement de la vulnérabilité de sécurité et des défenses requises lors de l'exploitation de plateformes/services d'écosystèmes intelligents spécifiques.

À mesure que l'intelligence artificielle et d'autres technologies avancées prennent de l'importance et créent des supersociétés, nous sommes également confrontés à des cybermenaces supplémentaires. Par exemple, les cybercriminels peuvent utiliser l'IA pour mener des cyberattaques plus sophistiquées. En même temps, l'IA peut être un outil contre la cybercriminalité, offrant aux organisations une technologie sophistiquée pour gérer des tâches de sécurité telles que la détection d'activités suspectes dans le système. De plus, l'IA peut être utilisée dans les tests, comme la simulation d'attaques système pour aider les professionnels de la cybersécurité à identifier les zones de risque et les vulnérabilités qui devraient être traitées. Selon IBM, l'IA peut aider à protéger les données dans les environnements de nuage hybride avec des outils tels que l'identification des données fantômes et la surveillance des anomalies de données. L'IA peut également créer des résumés d'incidents et automatiser les réponses à ces incidents, améliorant les enquêtes et les résultats. La capacité de l'IA à analyser les tentatives de connexion et à vérifier les utilisateurs peut réduire les coûts de fraude jusqu'à 90 %.39

Méthodologies d'assurance de la cybersécurité des plateformes d'écosystèmes intelligents du métavers

Pour se protéger contre les cybermenaces dans le métavers, les organisations devraient utiliser bon nombre des mêmes mesures de sécurité que celles utilisées pour se protéger contre les cybermenaces sur Internet. Elles doivent également faire face à de nouveaux risques de cybersécurité qui pourraient entraîner des pertes financières, des atteintes à la marque et à la réputation, et des défis juridiques.

Figure 14.53 illustre les quatre couches typiques des plateformes du métavers ainsi que huit menaces majeures dans le monde virtuel du métavers.

Figure 14.53 Le métavers comporte quatre couches de plateforme qui font généralement face à huit catégories de cybermenaces. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Assurance des plateformes de systèmes autonomes de supersociété

Les plateformes de systèmes autonomes sont un composant essentiel de l'avenir de l'intelligence artificielle. Elles fournissent les outils et les cadriciels pour construire, tester et déployer des systèmes autonomes qui peuvent fonctionner dans une variété d'environnements. Cependant, il existe divers défis en matière de sécurité des données/confidentialité (privacy), des défis réglementaires et des préoccupations éthiques associés aux plateformes de systèmes autonomes. Le fait que les systèmes autonomes reposent sur de grandes quantités de données soulève des préoccupations concernant la sécurité des données et la confidentialité. Comme ce fut le cas pour les plateformes IA/ML des écosystèmes intelligents discutées précédemment, qui sont confrontées au même type de problèmes, il n'est pas toujours possible de simplement s'appuyer sur l'établissement d'architectures de sécurité/confiance infonuagiques et de processus de gouvernance infonuagique. L'utilisation d'outils tiers pour remédier au manque d'extensibilité de la plateforme infonuagique d'un FSI peut introduire des vulnérabilités et nécessite des mécanismes de défense supplémentaires. Le déploiement de systèmes autonomes est également soumis à diverses réglementations et normes qui ne sont généralement pas couvertes par les architectures de sécurité/confiance infonuagiques et les processus de gouvernance. Par conséquent, des composants et processus d'architecture de sécurité supplémentaires devront être recherchés et fournis en fonction du domaine d'application de la plateforme autonome. Enfin, les systèmes autonomes soulèvent des préoccupations éthiques concernant des questions telles que la responsabilité, la transparence et les biais. Ces aspects devraient être couverts dans les architectures de sécurité/confiance infonuagiques et les processus de gouvernance infonuagique.

Assurance des plateformes de robotique avancée de supersociété

Les plateformes de robotique avancée de supersociété fournissent les outils et les cadriciels pour construire, tester et déployer des robots alimentés par l'IA qui peuvent travailler aux côtés des humains. Les défis techniques associés à la sécurisation des plateformes de robotique avancée sont analogues à ceux de la sécurisation des plateformes de systèmes autonomes, qui ont été abordés dans Assurance des plateformes de systèmes autonomes de supersociété. Reportez-vous à cette discussion pour passer en revue les défis de sécurité et les défenses associées qui doivent être mises en place. En plus de ces défis techniques, il existe également des problèmes sociaux, juridiques et éthiques connexes pour une intégration transparente des humanoïdes dans nos sociétés. De nombreuses recherches sont axées sur cet aspect aujourd'hui. Une question est de savoir s'il devrait y avoir des lois spéciales pour régir les robots.

Assurance des plateformes de nanotechnologie de supersociété

La nanotechnologie est l'une des technologies de supersociété qui permettent d'améliorer les services existants pour renforcer les services d'écosystèmes intelligents et soutenir les plateformes de supersociété. L'émergence de la nanotechnologie présente un tout nouvel ensemble de risques potentiels, ainsi que des solutions potentielles à la cybersécurité. Parce que la nanotechnologie implique la manipulation de la matière à l'échelle atomique ou moléculaire, il n'est pas trop farfelu de penser qu'elle pourrait permettre le développement de matériaux "intelligents" capables de détecter et de réagir aux logiciels malveillants ou aux menaces. La nanotechnologie pourrait également permettre la création de minuscules capteurs capables de détecter les accès non autorisés aux réseaux ou aux données. L'utilisation de la nanotechnologie en cybersécurité pourrait offrir aux utilisateurs un niveau de confidentialité et de sécurité accru. Par exemple, les nanomatériaux pourraient être utilisés pour créer des clés de chiffrement beaucoup plus difficiles à casser que les méthodes actuelles. De plus, l'utilisation de la nanotechnologie pourrait faciliter la détection et la prévention des violations de données. Cependant, l'utilisation de la nanotechnologie présente également certains risques potentiels. Par exemple, l'utilisation de nanomatériaux pourrait créer de nouvelles vulnérabilités qui pourraient être exploitées par des acteurs malveillants. De plus, l'utilisation de la nanotechnologie pourrait conduire à la création de dispositifs ou de systèmes trop complexes pour que les humains puissent les comprendre ou les contrôler.

L'une des applications les plus prometteuses des matériaux avancés en cybersécurité aujourd'hui est l'utilisation du graphène. Ce matériau bidimensionnel, composé d'une seule couche d'atomes de carbone, possède de nombreuses propriétés qui le rendent idéal pour les applications de sécurité. Il est très conducteur, solide et léger, et est imperméable à de nombreuses substances. Le graphène a déjà été utilisé dans une variété de dispositifs, y compris les puces informatiques, les écrans tactiles et les étiquettes RFID, et son potentiel pour les applications de cybersécurité est vaste. Une autre application des matériaux avancés en cybersécurité est l'utilisation de nanomatériaux. Les nanomatériaux, tels que les nanotubes et les nanofils, sont incroyablement petits, ce qui les rend difficiles à détecter. Cela les rend idéaux pour une utilisation dans les systèmes de chiffrement et d'authentification, où le moindre détail peut faire toute la différence. De plus, les nanomatériaux peuvent être utilisés pour développer de nouveaux types de capteurs capables de détecter les intrusions et les tentatives d'accès non autorisées.

Dans l'ensemble, la nanotechnologie a le potentiel de révolutionner le monde de la cybersécurité, tant en termes de solutions qu'elle offre que de risques qu'elle crée. À mesure que cette technologie continue de se développer, il est important que l'industrie de la sécurité s'efforce de maximiser les avantages de la nanotechnologie tout en minimisant les risques. Cela semble être le seul moyen de mettre en œuvre l'assurance des plateformes de nanotechnologie de supersociété (supersociety).

Assurance des plateformes de supercalcul de supersociété

Le supercalcul est une autre technologie de supersociété qui permet d'améliorer les services existants pour renforcer les services d'écosystèmes intelligents et soutenir les plateformes de supersociété. C'est aussi une technologie qui a le potentiel de révolutionner le monde de la cybersécurité, tant en termes de solutions qu'elle offre que de risques qu'elle crée. En ce qui concerne les risques, la vitesse de traitement considérablement accrue associée à l'utilisation d'ordinateurs quantiques ou neuromorphiques aura certainement un impact sur certains des algorithmes de cryptographie actuellement utilisés. En particulier, alors que le chiffrement à clé symétrique et les fonctions de hachage résistantes aux collisions sont considérés comme relativement sûrs contre les attaques par des ordinateurs quantiques, les schémas de signature basés sur le problème de la factorisation des entiers, le problème du logarithme discret ou le problème du logarithme discret sur courbe elliptique peuvent être résolus avec l'algorithme de Shor avec un ordinateur quantique suffisamment puissant. Du côté positif, les ZKP non interactifs qui ne sont que des fonctions de hachage résistantes aux collisions sont plausiblement sécurisés post-quantique et peuvent être utilisés pour remplacer les schémas de signature traditionnels basés sur la cryptographie à clé publique qui ne sont pas résistants aux attaques quantiques. Le supercalcul améliorera également la vitesse des calculs cryptographiques nécessaires pour faire fonctionner des plateformes sécurisées telles que la chaîne de blocs et optimisera davantage la vérification des transactions. Encore une fois, à mesure que cette technologie continue de se développer, il est important que l'industrie de la sécurité s'efforce de maximiser les avantages du supercalcul du point de vue de la cybersécurité tout en minimisant les risques. Cela semble être le seul moyen de mettre en œuvre l'assurance des plateformes de supercalcul de supersociété.

Assurance des plateformes de supersystèmes autonomes de supersociété

Les défis techniques associés à la sécurisation des supersystèmes autonomes sont analogues à ceux de la sécurisation des plateformes de systèmes autonomes, qui ont été abordés dans Assurance des plateformes de supercalcul de supersociété. Reportez-vous à cette discussion pour passer en revue les défis de sécurité et les défenses associées qui doivent être mises en place. La seule différence est le fait que les supersystèmes utiliseront de nouvelles technologies de supersociété émergentes telles que la nanotechnologie et le supercalcul. Compte tenu des défis éthiques et sociaux en matière d'utilisabilité (du point de vue de la qualité TRM), on craint de plus en plus que l'utilisation combinée des diverses technologies de supersociété décrites précédemment pour alimenter les supersystèmes autonomes puisse causer des menaces à l'humanité et aux civilisations futures. Il sera donc important pour l'industrie de la sécurité de veiller à ce que les avantages de ces technologies soient maximisés tout en minimisant les risques. Cela semble être le seul moyen de mettre en œuvre l'assurance des plateformes de supersystèmes autonomes de supersociété.