Lutter contre Log4Shell : l’appliance durcie Kiteworks porte bien son nom
Si vous demandez à un expert en cybersécurité ou à un RSSI s’il se souvient de la journée 9 décembre 2021, il y a fort à parier que cette personne réponde par l’affirmative. Ce jour-là, les entreprises du monde entier se sont précipitées pour mettre à jour en urgence la quasi-totalité de leurs systèmes et infrastructures informatiques stratégiques. Cela fait suite à la publication de la vulnérabilité Log4Shell, une faille majeure dans la bibliothèque Log4j alors très utilisée. Cette dernière permet à toute personne disposant d’une connexion Internet d’exécuter à distance des codes arbitraires sur les systèmes d’exploitation des produits vulnérables.
Chez Kiteworks en revanche, il n’y a pas eu besoin de correctif urgent ce jour-là, même si la solution utilise Log4j. Grâce à sa stratégie de sécurité multicouche, l’appliance renforcée Kiteworks a automatiquement réduit le score CVSS de la vulnérabilité de 10,0 à 4,0 (au maximum). Les utilisateurs de Kiteworks étaient sûrs que leurs données les plus sensibles étaient bel et bien en sécurité.
Protéger de l’intérieur
Pour reprendre le poète anglais John Donne, « aucun système n’est une île à part entière », et Kiteworks ne déroge pas à la règle. De par sa nature même, Kiteworks est un système connecté, permettant aux utilisateurs de collaborer entre eux (internes et externes) de manière sûre, sécurisée et conforme. Autrement dit, Kiteworks doit se connecter à d’autres systèmes et autoriser d’autres systèmes et utilisateurs à s’y connecter. La difficulté est donc de garantir que rien ni personne n’entre ou ne sort du système sans autorisation ni contrôle, conformément au principe de sécurité zéro trust.
C’est dans cette optique que nous avons créé l’appliance durcie Kiteworks.
Système d’exploitation minimaliste
L’appliance durcie Kiteworks passe tout d’abord par l’installation du système d’exploitation Linux de base, pourvu du strict minimum de bibliothèques et d’applications système nécessaires à son fonctionnement. L’équipe DevOps de Kiteworks installe ensuite un ensemble de bibliothèques externes sélectionnées avec soin, toutes indispensables au fonctionnement de Kiteworks et approuvées par nos experts.
La liste des bibliothèques utilisées est analysée en permanence et comparée à une base qui recense les vulnérabilités connues. Cette analyse assure que l’appliance renforcée Kiteworks soit toujours à jour avec les derniers correctifs et mises à jour de sécurité.
En résumé, une appliance durcie Kiteworks ne contient aucun port actif ou service superflu.
Zéro trust (fonctionne dans les deux sens)
Dans le même ordre d’idée, les composants internes de l’appliance durcie Kiteworks ne sont accessibles que depuis un seul compte système. Les autres comptes système sont rares et leurs autorisations très limitées, conformément au « principe du moindre privilège ». Ils ne sont pas autorisés à accéder de manière interactive à l’appliance.
Pour garantir l’intégrité de l’appliance durcie, le compte d’assistance technique ne peut être utilisé que par un ingénieur certifié Kiteworks. Aucun client ne reçoit jamais le mot de passe de ce compte, même si l’appliance est installée sur site et dans son propre data center.
Néanmoins, Kiteworks garantit que la connexion ne peut se faire qu’avec l’accord explicite préalable du client. En fonctionnement normal, seul l’administrateur client peut accéder à son compte ; Kiteworks ne connaît pas le mot de passe du compte et n’y a pas accès. En cas de problème, l’administrateur système peut générer un nouveau mot de passe chiffré et le transmettre à l’ingénieur support. Ce dernier pourra alors le déchiffrer et l’utiliser pour se connecter.
Résultat : une solution garantie zéro trust et à double sens.
Contrôle interne
Toutes les appliances durcies Kiteworks sont équipées de procédures internes pour surveiller et appliquer des politiques très strictes concernant le comportement supposé des systèmes d’exploitation et des fichiers. Si, pour une raison ou pour une autre, une appliance renforcée Kiteworks déviait de sa fonction initiale (par exemple si un fichier est modifié ou créé à un endroit où il n’était pas censé l’être, ou si un service consulte un port inhabituel), l’interface enverrait automatiquement une alerte à l’administrateur.
L’appliance renforcée conserve également des journaux détaillés de l’activité de tous les services critiques. Les administrateurs système peuvent ainsi surveiller le fonctionnement interne de Kiteworks en temps réel à l’aide de leurs propres outils de gestion des informations et des événements de sécurité (SIEM) et d’autres outils d’orchestration, d’automatisation et de réponse de sécurité (SOAR).
Sandboxing interne
Comme évoqué précédemment, le fonctionnement de Kiteworks nécessite parfois l’utilisation de bibliothèques externes, qu’elles soient open source ou payantes. Kiteworks utilise au maximum ces bibliothèques à l’intérieur d’un bac à sable (ou sandbox) au niveau du système d’exploitation. Pour résumer, bien qu’une bibliothèque externe soit installée, son accès à d’autres parties du système d’exploitation ou de fichiers systèmes est très limité. Ainsi, si jamais une vulnérabilité était découverte dans l’une de ces bibliothèques, la menace pour l’appliance durcie Kiteworks serait largement réduite.
Application des politiques réseau
Pour assurer que l’état d’origine du système d’exploitation s’applique aussi du côté du réseau, toutes les appliances durcies Kiteworks ont une configuration interne de pare-feu très stricte. Le trafic réseau entrant n’est autorisé que par les canaux et les ports requis et attendus.
Protections réseau supplémentaires
Toutes les appliances durcies Kiteworks sont équipées de mécanismes pour surveiller et bloquer les connexions et les requêtes web malveillantes. Au-delà de la configuration statique du pare-feu, nous utilisons un blocage dynamique des requêtes malveillantes pour bloquer les connexions réseau sur des ports inattendus. Enfin, les auteurs d’infractions répétées seront automatiquement et complètement bloqués, afin de garantir le bon fonctionnement et la sécurité de l’appliance et de la solution Kiteworks.
Accédez à Log4j
Log4j est une bibliothèque open source de journalisation d’événements mise à disposition par la fondation Apache. La fondation elle-même est soutenue par de grandes marques internationales, comme Google, Microsoft, Amazon et Apple. Du fait de la notoriété de son fournisseur, de ses avantages et de sa simplicité d’utilisation, Log4j est rapidement devenue l’une des bibliothèques les plus populaires au monde, largement utilisée par la plupart des grands éditeurs de solutions. Kiteworks est l’un d’entre eux.
En décembre 2021, une vulnérabilité majeure a été découverte dans Log4j. Après enquête, la base de données nationale sur les vulnérabilités (NVD) gérée par le National Institute of Standards and Technology (NIST), lui a attribué le score CVSS de 10.0, le plus élevé qui soit.
Ce système de notation prend en compte de nombreux critères axés sur la facilité d’exploitation et l’étendue des dommages potentiels. La vulnérabilité de Log4j, connue sous le nom de Log4Shell, permet à quasiment n’importe quelle personne non authentifiée de faire exécuter un code malveillant dans n’importe quel système vulnérable.
Log4j étant un composant très répandu, on comprend aisément comment cette affaire a pu avoir des répercussions mondiales en l’espace d’une seule nuit.
L’appliance durcie de Kiteworks : la solution idéale !
Alors que de nombreux fournisseurs à travers le monde ont dû alerter leurs clients sur la nécessité de publier des correctifs en urgence, Kiteworks n’en a pas eu besoin.
Après une enquête approfondie, l’équipe de sécurité de Kiteworks a conclu que le score CVSS de la vulnérabilité serait tout au plus de 4 dans le contexte de l’appliance renforcée. Et à ce jour, rien ne prouve qu’il existe un moyen d’exploiter la vulnérabilité de Kiteworks. Voici quelques leçons à tirer de cette expérience :
- Conformément au principe du moindre privilège, la bibliothèque vulnérable a été installée et utilisée avec une configuration très restrictive. Les API vulnérables étaient désactivées et donc non exploitables.
- La bibliothèque vulnérable fonctionnant à l’intérieur de son propre bac à sable, il lui était impossible d’exécuter un quelconque code externe et encore moins un code malveillant. Par conséquent, même exploitée, la menace potentielle était fortement atténuée.
- La bibliothèque étant très surveillée, tout écart par rapport à son fonctionnement habituel aurait été remarqué et signalé. Or, cela n’a jamais été le cas.
Malgré les précautions déjà prises, nous n’avons pas pris de risques. La version suivante de Kiteworks a intégré un correctif et de multiples mécanismes pour empêcher toute possibilité d’exploitation.
Parmi ces mesures figurent :
- Une version améliorée, sans risque de vulnérabilité, de cette bibliothèque
- Une nouvelle configuration de la bibliothèque pour désactiver expressément le paramètre vulnérable. Au cas où les API vulnérables seraient activées, la sécurité resterait assurée.
- Une mesure de protection spécifique à notre réseau interne, qui bloque toute requête web provenant directement de Log4j.
En savoir plus sur l’appliance durcie Kiteworks
Les clients de Kiteworks bénéficient d’une plateforme pour échanger facilement leurs données les plus sensibles, en interne ou en externe, en toute sécurité. Pour répondre à leurs attentes, Kiteworks a conçu une appliance durcie avec plusieurs niveaux de sécurité, ce pour résister non seulement aux attaques connues, mais aussi à d’éventuelles menaces encore inconnues.
Pour en savoir plus sur l’appliance renforcée Kiteworks, réservez dès maintenant votre démo personnalisée du Réseau de contenu privé Kiteworks.
Ressources complémentaires