Culture et connaissances en cybersécurité

1. Le CIA (Confidentialité, Intégrité et Disponibilité)

En sécurité informatique, il est commun d’utiliser le CIA pour décrire les principes fondamentaux qui régissent la mise en place de politiques de sécurité. Cette section est importante, puisqu’il arrive assez souvent que des termes soient utilisés à la place d’autres, pour parler de choses qui n’ont parfois rien à voir.

Tout d’abord, le CIA ne désigne pas la Central Intelligence Agency, comme on pourrait le croire de premier abord. Il fait référence aux termes anglais Confidentiality (confidentialité), Integrity (intégrité) et Availability (disponibilité). Détaillons ces différents éléments :

Confidentiality : seules les personnes autorisées peuvent avoir accès aux données.

Integrity : la donnée ne peut pas être modifiée par des personnes non autorisées. Alors que ce terme est souvent utilisé pour indiquer l’intégrité des données lorsqu’elles traversent le réseau d’un point A à un point B, il fait en fait référence à l’intégrité des données en tout point du réseau, que ce soit lors de sa création, de son transfert ou de son stockage.

Availability : la donnée est disponible pour les personnes autorisées, quand et où elles en ont besoin.

Il est possible que vous trouviez les mêmes termes dans un ordre différent comme avec l’AIC (Availability, Integrity and Confidentiality). Ce n’est...

1. Les attaques par reconnaissance

La plupart des attaques ne sont pas dirigées sur votre réseau en entier. Il existe d’ailleurs de nombreuses attaques réseau dont l’objectif est de récupérer un maximum d’informations pour les attaques futures, tout en restant totalement inaperçues : ce sont les attaques par reconnaissance (recon en anglais).

Les attaques de type recon recherchent des faiblesses ou des vulnérabilités dans les défenses de votre réseau. Lorsque des vulnérabilités sont trouvées, elles ne sont pas directement exploitées par l’attaque recon, mais les informations inhérentes à ces vulnérabilités sont remontées aux attaquants afin de leur permettre de mieux organiser des attaques futures qui, elles, vont cibler spécifiquement ces vulnérabilités. Un bon attaquant cherche à obtenir un maximum d’informations sur l’infrastructure qu’il souhaite attaquer, plutôt que de lancer des attaques à l’aveugle.

L’absence apparente de dégâts causés par les attaques de type recon est totalement volontaire puisque l’attaquant veut passer inaperçu. Si jamais les administrateurs détectent ce type d’attaque, ils prennent immédiatement les contre-mesures nécessaires, ce qui va empêcher l’attaquant d’arriver à ses fins. Bien sûr, les dommages causés par l’attaque suivant la reconnaissance vont, eux, être probablement bien visibles.

2. Le Social Engineering

Les attaques de type Social Engineering se concentrent sur la partie la moins prévisible de notre infrastructure, c’est-à-dire l’humain. En général, l’humain est une des plus grosses failles de sécurité existantes. On peut souvent récupérer beaucoup plus d’informations en effectuant du Social Engineering qu’en essayant d’attaquer directement un firewall, un serveur ou une application.

Pour preuve, le patron d’une grande société (dont le nom est volontairement tu) avait demandé à une société spécialisée dans les audits de sécurité...

1. Qu’est-ce qu’une attaque par déni de service ?

Une attaque par déni de service consiste à rendre indisponible un service et empêcher les utilisateurs d’y accéder. Il faut bien les distinguer des attaques par reconnaissance, puisque celles-ci ont pour but de passer inaperçues et de récupérer un maximum d’informations. 

Les attaques de type déni de service ont uniquement pour but de saturer le service ciblé en lui envoyant tellement d’informations qu’il n’est plus capable de les gérer correctement. En réalité, le service utilise toutes ses ressources pour répondre aux requêtes envoyées par l’attaquant, et n’en possède plus suffisamment de disponibles pour répondre aux requêtes des clients légitimes.

Les attaques de type DDoS (Distributed Denial of Service) impliquent l’utilisation de botnets, un groupe d’équipements sous le contrôle de l’attaquant. Ces équipements ont pu être placés sous son contrôle grâce à divers malwares que le véritable propriétaire a pu télécharger par inadvertance. L’attaquant possède alors à son service des ordinateurs zombies, lui permettant de démultiplier le nombre d’attaquants et leur position géographique.

Il arrive cependant parfois qu’une situation de déni de service ne soit pas due à une attaque. Par exemple, au début de la mise en place du site internet permettant de régler ses impôts...

1. Les attaques Man-in-the-Middle (MITM)

Ce type d’attaque va consister à intercepter et modifier les communications existantes entre deux parties ; un client et un serveur la plupart du temps. Au sein des pipelines CI/CD, cela peut toucher les communications entre un Runner CI/CD et un registre Docker, ou des API non sécurisées qui sont utilisées à l’intérieur des pipelines.

Imaginons que votre Runner GitLab établisse une connexion avec un registre Docker non sécurisé via HTTP afin de récupérer une image.

Un attaquant pourrait très bien s’interfacer entre le registre Docker et le Runner GitLab et agir comme un proxy qui va intercepter l’ensemble des requêtes et modifier la réponse du registre en faisant télécharger une image Docker malveillante (qui ressemble à l’image initialement recherchée) contenant une backdoor à l’intérieur de la pipeline CI/CD.

Heureusement, il existe des contre-mesures simples, comme le chiffrement...

1. Principe de fonctionnement du chiffrement

Dans cette section, nous allons aborder le fonctionnement du chiffrement, et non pas du « cryptage », qui correspond à une notion différente.

Prenons l’exemple de Bob et Alice qui souhaitent communiquer en s’envoyant des messages ou des fichiers.

La confidentialité signifie que les deux parties (émettrice et réceptrice) peuvent communiquer de manière confidentielle de façon que, si le message est intercepté par une autre partie non autorisée, celle-ci ne puisse pas déchiffrer le contenu du message.

Il est alors nécessaire de procéder à un chiffrement du contenu du paquet de données grâce à des algorithmes (on parle de cypher en anglais).

Prenons par exemple le message chiffré visible ci-dessus : « Cpokpvs kf n’bqqfmmf Kpsebo BTTPVMJOF ».

Si vous interceptez ce contenu et que vous ne savez pas comment faire pour le déchiffrer (donc que vous n’avez pas la clé vous permettant de déchiffrer le message), vous n’êtes pas en mesure de comprendre le contenu de ce message.

En général, les parties émettrice et réceptrice s’échangent la clé avant d’envoyer le message, pour permettre au récepteur de savoir de quelle manière ce message doit être déchiffré.

Dans l’exemple ci-dessus, c’est un algorithme de chiffrement symétrique qui est utilisé (nous reviendrons sur cette notion un peu plus tard dans ce chapitre), c’est-à-dire qu’il est possible de récupérer le message original à partir du message chiffré, lorsque nous sommes en possession de la clé de déchiffrement.

En effet, la clé de déchiffrement consiste à prendre la lettre suivant la lettre originale dans l’alphabet (par exemple on remplace A par B, B par C, V par W, etc.). On obtient ainsi le message original suivant : « Bonjour je m’appelle Jordan ASSOULINE ».

Ce n’est donc pas si facile de trouver la clé en ne possédant que le message chiffré, même dans des cas relativement simples comme celui-ci…

En conclusion, le chiffrement...

1. Qu’est-ce qu’un certificat digital ?

Commençons par chercher à comprendre ce qu’est un certificat digital, et comment il utilise les différentes notions liées à la cryptographie dont nous avons discuté dans les parties précédentes.

Dans la section liée aux notions de clés publique et privée, nous avons déjà abordé le principe de fonctionnement des signatures numériques.

C’est l’autorité de certification qui a pour but de générer des certificats digitaux.

Les certificats digitaux reprennent en grande partie les notions de cryptographie et de chiffrement, en les appliquant de manière à fournir des certificats qui valident :

Chaque certificat délivré pour un site web peut être observé, notamment en cliquant sur le cadenas dans votre navigateur web.

Il existe plusieurs autorités publiques de certification, qui font payer aux tiers la délivrance et le maintien de ces certificats. Il est possible, bien entendu, de créer sa propre autorité de certification pour délivrer, au sein de l’entreprise, des certificats pour chaque équipement. Cependant, ces certificats ne seront pas reconnus comme étant « de confiance » par les utilisateurs extérieurs à la société, et n’auront donc de valeur que locale.

Il faut bien comprendre que ces certificats permettent aux utilisateurs d’être certains que l’équipement avec lequel ils sont en train de discuter (ici le serveur web de Google.fr) est bien l’équipement réel et officiel et non une copie qui serait destinée, par exemple, à récolter leurs données bancaires ou d’identification.

Parmi les éléments importants des certificats, vous pouvez retrouver :

1. Introduction au rôle de la cryptographie en DevSecOps

Il est légitime de se poser la question de l’intérêt de la cryptographie dans l’univers du DevSecOps. Elle est essentielle et correspond à un des piliers centraux, trop souvent délaissé à tort. En effet, les pipelines CI/CD échangent souvent des données sensibles comme des clés, des identifiants, des secrets. Or ces données doivent être protégées à tout moment, et la cryptographie et plus spécifiquement les techniques de chiffrement correspondent à une solution potentielle. Il est également essentiel de pouvoir s’assurer que les parties autorisées puissent accéder aux systèmes ou lancer des jobs et des builds, et que celles qui ne le sont pas ne puissent pas effectuer d’actions qui pourraient être délétères. Enfin, la cryptographie nous donne la possibilité de vérifier que les artefacts et les images, ainsi que les communications n’ont pas été altérés, nous assurant ainsi de leur intégrité.

Nous pouvons nous prémunir d’un certain nombre d’attaques et de menaces comme :

2. TLS1.3 et DevSecOps

Le TLS (Transport Layer Security) est un protocole permettant de sécuriser les communications au sein d’un réseau. Il permet de garantir la confidentialité des échanges (avec du chiffrement), l’authenticité des parties impliquées dans la communication (avec des certificats) et l’intégrité des données qui transitent à travers le réseau.

Il s’agit donc d’une fonctionnalité critique dans les pipelines CI/CD puisque les communications y sont omniprésentes : avec les Runners, les dépôts de code, les registres d’images Docker, les services Cloud, etc. D’autant que l’ensemble de ces échanges impliquent des données...