Malware Corner

p. 06 Techniques de contournement de la supervision des EDR

Pentest Corner

p. 16 Audit d’applications Android, Java ne répond plus !

Forensic Corner

p. 24 Description du système de fichiers ExFAT

Dossier : Techniques d'OSINT à l'usage des honnêtes gens

p. 30 Introduction
p. 31 OSINT : de l’importance d’une approche méthodologique décentrée des outils
p. 38 L’Open Source Intelligence, un jeu ?
p. 46 Faciliter son Red Team grâce à l’OSINT

Système

p. 52 Exemples d’utilisation d’un TPM (Trusted Platform Module)

Code

p. 64 Première plongée dans le noyau de Windows

Organisation & juridique

p. 74 CTF : un outil pour la sensibilisation large à distance

Too big to fail Les principaux fournisseurs de Cloud peuvent proposer des SLA bien au-delà de ce que la plupart des DSI sont en capacité d’atteindre. Ainsi, pour une DSI, faire le choix de déployer ses applications sur un IaaS ou d’opter pour une messagerie en mode SaaS chez Google ou Microsoft permettra de garantir une certaine tranquillité d’esprit quant à l’amélioration du taux de disponibilité des applications gérées en interne sur ses propres infrastructures. N’en déplaise aux pseudos-spécialistes affirmant que l’auto-hébergement, parfois derrière une ligne ADSL pour les plus hardis, est à privilégier, c’est très loin d’être la solution la plus fiable. Pour atteindre un SLA de 99,9% à 99,99%, il faut non seulement un data center Tiers 3, plusieurs accès opérateurs avec des arrivées fibres empruntant des chemins distincts afin que la connectivité internet ne soit pas le maillon faible, mais surtout des briques logicielles sur lesquelles il doit être possible de réaliser des opérations de maintenance sans rupture de service.

Pourtant, quand bien même les pannes sur les acteurs majeurs de Cloud sont rares, l’actualité récente montre qu’elles ne sont pas impossibles. Les récentes avaries de Facebook et OVH en octobre nous rappellent qu’opérer un Cloud n’est pas de la magie et que les erreurs humaines existent. Et si, à l’époque où l’hébergement interne était la norme, les ruptures de productions arrivaient régulièrement dans les entreprises à la suite d’une avarie technique, une erreur humaine ou une simple panne de courant électrique, celles-ci ne touchaient que l’entreprise concernée. Et quand nous imaginions une panne globale d’Internet, nous avions en tête une faille de sécurité découverte sur le protocole BGP ou une attaque coordonnée sur les DNS racines.

Ce que le Cloud a foncièrement changé c’est la concentration des infrastructures de production et le fait qu’une panne sur un fournisseur de services peut toucher des milliers d’entreprises. Ainsi, lorsque Facebook perd ses liens BGP, ce ne sont pas juste les réseaux sociaux récréatifs ou professionnels de la société qui sont inaccessibles, mais également tous les sites utilisant Facebook comme fournisseur d’identité et d’authentification. Imaginons une panne majeure des infrastructures Microsoft Azure et un nombre considérable d’entreprises se trouvent totalement inopérantes, les utilisateurs ne pouvant plus ouvrir de sessions (Azure AD), accéder à leurs fichiers (Sharepoint), lire ou envoyer des e-mails (Office 365), faire des visioconférences ou accéder aux projets en cours (Teams). Si c’est Google qui tombe, plus d’e-mails pour les particuliers et bon nombre d’entreprises, et « plus d’Internet » pour ceux qui utilisent Google comme cache DNS ou ne savent plus saisir une URL dans Chrome. Enfin, si c’est AWS, le Web ressemblerait à une ville fantôme avec une grande partie des sites inaccessibles ou dysfonctionnels, et côté entreprise, beaucoup d’applications cassées.

Dès lors, si à l’échelle d’une entreprise, le recours à ces géants a du sens, car ils fournissent des SLA difficilement atteignables sans une armée d’ingénieurs et des infrastructures à discrétion. Cependant, à l’échelle d’un ou plusieurs pays, faire reposer l’économie et plusieurs services essentiels sur une poignée d’acteurs, qui en cas de défaillance technique, humaine ou d’une attaque pourrait cesser de fonctionner a de quoi faire frémir tant l’impact serait important.

Ce problème est d’autant plus complexe à aborder, que nous sommes passés majoritairement d’un modèle IaaS à du SaaS et du PaaS. Et s’il était tout à fait faisable de déployer des VM sur plusieurs fournisseurs de Cloud, dans un modèle orienté application, comme il devient majoritaire, c’est largement plus complexe. Il va être difficile de basculer dans l’heure vers Google Workplace si les services Azure AD, Sharepoint et Office 365 sont inaccessibles rendant son parc totalement inutilisable de même que toute communication interne. Ceci est d’autant renforcé par le modèle de vente de Google et Microsoft qui louent leurs services sous forme de bundle plutôt qu’à la carte. Il n’est ainsi pas possible d’acheter chez Google uniquement la solution de messagerie collaborative et chez Microsoft la visioconférence. Cela induit qu’il est très désavantageux financièrement de panacher les services chez plusieurs éditeurs, car cela revient à les payer plusieurs fois.

Ainsi, si les DSI et RSSI d’entreprises ont, à leur échelle, pu améliorer les SLA de leurs applications en les migrant dans le Cloud, ce choix collectif a fortement augmenté l’impact d’une défaillance sur le fonctionnement global des outils numériques à l’échelle mondiale.

Cédric Foll / cedric@miscmag.com / @follc