Le système d’information était déjà compromis

La FIR (Force d’Intervention Rapide) était sur les lieux depuis un peu plus d’une heure lorsque la première action de remédiation fut mise en œuvre.

L’idée était d’isoler le sous-réseau dans lequel s’exécutaient les machines infectées avant de rediriger le trafic client vers l’infrastructure de secours.

Plusieurs heures interminables d’interruptions de service venaient de s'écouler et le RSSI avait vécu le cauchemar qu’il s'était promis d'éviter en acceptant son poste huit mois plus tôt.

Ce qu’il ignorait, c’est qu’au moment de conclure son arrivée par la symbolique poignée de main du DSI, le système d’information dont il héritait du devoir de protection était déjà compromis.

Il ne s’agissait pas d’un manquement évident de la part de son prédécesseur. Les correctifs avaient toujours été appliqués en temps et en heure. La veille sur les vulnérabilités était faite et les audits exécutés avec sérieux.

Le budget alloué aux solutions de sécurité, à la sensibilisation des utilisateurs ou au recrutement des ingénieurs cyber était honorable. Pourtant, lors d’une froide nuit d’hiver, l'EDR et les CPU s’emballèrent tandis que le pirate échouait à faire passer son cryptominer sous le radar.

Vous pourriez hâtivement penser que la fin est heureuse puisque les tentatives d’exécution du malware furent immédiatement bloquées et le SOC averti. Mais qu’en est-il du début ?

La société touchée a rendu honneur aux statistiques. La menace était présente dans le système depuis un peu plus de six mois, c’est-à-dire au-dessus du temps moyen de résidence. Le chargement de la bibliothèque malveillante, sa tentative d’exécution puis le déni de service qui a suivi ne sont que les actions grossières et décomplexées d’un attaquant certain que nombre d’actes plus silencieux auraient dû être détectés bien avant.

Comme toujours, la phase d’analyse post-mortem et l’identification du vecteur d’infection se sont déroulées avec un degré de stress moindre que l’urgence de la première heure d’intervention.

Une fois les logs soigneusement épluchés et les images mémoire des machines virtuelles passées au crible, l’historique des événements est peu à peu apparu.

La surface d'attaque était humaine

L’une des fastidieuses tâches de la sécurisation d’un système d’information consiste en l'énumération précise et au maintien de la liste des actifs sur le réseau de l’entreprise. Parmi les objectifs, on y retrouve l’obtention d'une vue générale des technologies employées et des risques associés. L’adage veut que la sécurité globale d’un système équivaut au niveau de protection de son maillon le plus faible, et la plupart des professionnels de la cyber approuvent volontiers cette vision.

En pratique, elle est à relativiser. C’est une vue de l’esprit. Il est rare qu’une société se défasse totalement du Shadow IT. Il arrive nécessairement que des systèmes et solutions obsolètes non référencés fassent partie du réseau, et que les vulnérabilités qui les affectent représentent une porte d’entrée idéale pour un pirate.

Est-ce pour autant que ces points d’entrée sont systématiquement choisis par les attaquants ? Sont-ils seulement toujours relevés lors de la phase de découverte qui précède les tentatives de compromission ? Il est courant que des vulnérabilités critiques, surtout dans les systèmes de tailles importantes, soient méconnues par les deux camps.

La défense, d’une part, par la difficile tâche que représentent les tentatives d’obtention de cette vue globale et précise du SI, et qui peut naturellement laisser échapper des oublis.

L’attaque, d’autre part, par habitude, mauvaise méthodologie, et parfois ce qu’elle pense être plus facilement abordable pour arriver à ses fins.

Ici, l’attaquant n’avait aucune raison de scanner les ports exposés sur internet par l’entreprise, d’essayer de découvrir des erreurs de configuration, des mots de passe par défaut, des erreurs de développement dans les applications, ou des systèmes non mis à jour. Il n’avait aucune raison de le faire, car il était déjà dans le réseau depuis de nombreuses années.

Il n’y était pas parvenu en envoyant un mail vérolé, en subtilisant des identifiants d’accès VPN, ou en manipulant les employés. Il n’avait pas non plus utilisé de kit de crochetage, déjoué des cameras de surveillance, ne s'était pas grimé en attendant devant la badgeuse et en tapotant ses poches d’un air hagard en espérant que quelqu’un lui ouvre l’accès.

Il n’avait rien fait de tout ça.

Il avait envoyé un CV et avait été reçu en entretien par les ressources humaines, puis par son futur manager.

Tout s'était passé dans l’ordre. Les questions techniques avaient été répondues avec justesse, et le salaire négocié, bien que jugé un peu élevé par l’entreprise, avait finalement été accepté. Le profil était recherché, et tout le monde se félicitait.

Pourtant, au moment de son entrée, le nouveau membre n’était animé d’aucune mauvaise intention.

Les choses évoluent. Au bout de plusieurs années, de conflits avec ses supérieurs ou bien par désœuvrement et appât du gain, la facilité d’accès et la connaissance des process internes tentent progressivement le jeune ingénieur de basculer dans l’illégalité.

L’utilisation quotidienne et la connaissance des paramètres de sécurité de son poste de travail ou du réseau, les discussions avec ses pairs, les accès qu’il a accumulés au fil des années le poussent à agir.

Ou peut-être est-ce la prime promise par le groupe qui l’a approché ?

Ainsi, pendant une trop longue période, les informations sensibles de la société ont été silencieusement récoltées. Elles ne seront publiées sur le darknet que plusieurs mois après la fin de l’incident, et bien après que le pirate en herbe ne décide de s'émanciper de son commanditaire pour œuvrer à son compte, et lever les premières alertes du SOC.

Ne jamais faire confiance, toujours vérifier

La loi des grands nombres n'épargne pas. Et là où le nombre de collaborateurs est important, le risque est mécaniquement plus élevé.

En quelques années, la notion de confiance en cybersécurité a évolué.

Il est aujourd’hui plus courant de considérer la sécurisation de son système d’information à travers une approche Zero Trust, souvent vue comme une philosophie, un ensemble de préceptes qui consistent à s'écarter d’un modèle manichéen dans lequel on considérait auparavant deux parties distinctes :

Le monde extérieur, dangereux, duquel il fallait se protéger, et qui représentait la menace principale. En d’autres termes, ce qui n'était pas dans le périmètre de l’entreprise, d’un point de vue technique ou humain, et qui exigeait validation pour mériter la confiance.
L’entourage proche, constitué des individus de confiance, qui avaient passé cette validation. De façon plus “IT”: tous les actifs de la société, considérés comme sains, et qui ne représentent pas de menace. Du moins, en théorie.

L’approche Zero Trust a comme paradigme d’entremêler ces deux mondes en considérant que tout milieu, tout individu, ou tout élément d’un système est potentiellement hostile, en appliquant des vérifications permanentes, considérant le principe de moindre privilège comme une base dont on ne peut se défaire, et en supposant que les menaces sont déjà présentes dans le système.

Le Zero Trust appliqué au réseau (Zero Trust Network Access ou ZTNA) est la solution technique de cette vision. Il est une façon de traduire l’aspect purement philosophique du Zero Trust en appliquant rigoureusement des règles qui permettent de lutter efficacement contre les menaces actuelles.

Pour ne pas rater les prochains billets sur le sujet :