L’architecture de sécurité de Java et la rapidité des correctifs critiques
En tant que composant fondamental de la plupart des applications d’entreprise et critiques, la plate-forme Java dispose d’une stratégie de sécurité extrêmement rigoureuse et bien structurée. Au sein du projet open source OpenJDK, il existe une équipe connue sous le nom d’OpenJDK Vulnerability Group (OVG). Malgré la nature ouverte du projet, cette équipe opère dans une totale intimité. L’adhésion au groupe est soigneusement contrôlée et seuls les ingénieurs possédant l’expérience et les compétences requises en matière de sécurité sont sélectionnés. Étant donné que des correctifs sont en cours de développement pour les vulnérabilités actuellement non corrigées (celles qui seraient classées publiquement comme zero-day), toutes les communications sont cryptées. Contrairement aux autres groupes du projet, les échanges emails de ce groupe ne sont pas publiés.
Sur la base du travail de l’OVG, un calendrier bien défini fournit les modifications du code source des correctifs de sécurité le troisième mardi de janvier, avril, juillet et octobre. La plupart (mais pas tous) des principaux fournisseurs de distribution binaire OpenJDK ont des représentants sur l’OVG. Cela garantit que les mises à jour des distributions d’exécution Java sont mises à la disposition des utilisateurs. En tant que principal développeur de Java, Oracle publie ses correctifs sous forme de mise à jour critique de correctifs (CPU) en même temps que le référentiel de code source est mis à jour. Une fois le processeur d’Oracle accessible au public, l’embargo sur les autres distributions OpenJDK est levé et ils sont libres de publier leur mise à jour. Le temps que cela prend dépend du fournisseur ; évidemment, plus le délai est long, plus le risque que des vulnérabilités non corrigées soient exploitées est grand. Pour Azul Core, qui inclut les versions Zulu d’OpenJDK, les mises à jour ont toujours été mises à disposition dans l’heure suivant la levée de l’embargo.
À quoi ressemble une bonne hygiène de sécurité Java maintenant
Pour garantir le plus haut niveau de sécurité pour vos applications basées sur JVM, vous devez disposer d’une stratégie bien définie pour déployer les mises à jour JDK dans votre parc. Il n’est que trop courant d’entendre des utilisateurs dire qu’ils n’ont pas besoin de patcher leurs machines parce qu’elles sont derrière un pare-feu. Un pare-feu n’est pas impénétrable. La faille Equifax mentionnée précédemment utilisait un exploit sur des machines situées en dehors du pare-feu ; Une fois ces machines compromises, les attaquants pouvaient traverser le pare-feu comme s’il n’existait pas.
