La plupart des professionnels de la sécurité pensent en termes de protection des ressources les plus précieuses, quelles qu’elles soient par rapport à leur activité spécifique. Bien que les données, les applications et les services de chaque entreprise soient différents, toutes les entreprises s’appuient sur des données et des applications/services pour fonctionner. Si ces éléments sont compromis d’une manière ou d’une autre, l’entreprise doit faire face à des répercussions (proportionnelles à l’ampleur de la compromission).
Quelle que soit l’ampleur d’un incident, chaque fois qu’une équipe de sécurité doit y répondre, cela signifie que la confidentialité, l’intégrité ou la disponibilité des données et/ou des systèmes ont été remis en question ; en d’autres termes, une personne ou une ressource système a obtenu un accès non autorisé aux ressources les plus précieuses de l’entreprise. Et même si, d’un point de vue théorique, ce dilemme trouve un écho auprès des professionnels de la sécurité, les ressources si précieuses des entreprises continuent d’être sécurisées à l’aide d’outils éloignés des ressources elles-mêmes, qui s’appuient en grande partie sur des adresses IP, des ports et des protocoles réseau que les hackers n’ont aucun mal à compromettre.
Il est important que les professionnels de la sécurité placent les éléments qu’ils sont chargés de protéger au centre de leur stratégie de sécurité. La réponse : l’identité de l’application.
L’identification des applications/services par leurs attributs/caractéristiques/propriétés immuables permet aux équipes de sécurité d’élaborer des politiques basées sur les applications et les données présentes, en cours d’exécution et qui communiquent sur le réseau. Cela permet d’extraire la politique de sécurité de l’infrastructure sous-jacente du réseau et de la relier directement aux ressources les plus précieuses.
Première clé de l’identité de l’application : caractéristiques immuables
L’identité d’une application doit reposer en grande partie sur des propriétés immuables (propriétés qu’un hacker ne peut pas modifier) et sur les signatures cryptographiques de l’application. Un exemple de propriété immuable serait le hachage SHA 256 d’un binaire. Si un seul bit de ce binaire change, ce hachage donnera une valeur différente. Une identité différente sera ainsi acquise.
Parmi d’autres exemples de caractéristiques immuables, citons des attributs tels que l’identifiant unique universel (UUID) du BIOS du système et les numéros de série des CPU, des éléments tellement fondamentaux pour le système qu’un hacker ne peut pas les modifier.
La clé de l’immuabilité consiste à s’assurer que les caractéristiques fondamentales d’une application ou d’un service demeurent suffisamment fiables pour identifier de manière unique chaque application/service à des fins de vérification dans un environnement Zero Trust, sans verrouiller l’application/le service de sorte que sa mise à niveau, sa mise à jour ou son amélioration sont impossibles.
Deuxième clé de l’identité de l’application : caractéristiques compréhensibles
L’un des problèmes liés à l’utilisation d’outils de sécurité traditionnels pour protéger les applications sur le réseau est la traduction du « langage de l’application » (la façon dont l’application a été écrite) en « langage du réseau » (la façon dont les outils de sécurité fonctionnent). Ce décalage s’est transformé en un véritable bras de fer entre de nombreuses équipes de développement et de sécurité.
Pour éviter ce genre de conflit, le fait d’utiliser des caractéristiques compréhensibles pour les applications afin de les définir signifie que les équipes chargées de la sécurité/du réseau et celles chargées du développement/des applications peuvent communiquer dans un langage commun. Les caractéristiques détournées, opaques ou arbitraires érodent la confiance des professionnels quant à leur utilité à fonctionner en tant qu’identificateurs. L’utilisation de caractéristiques qui ont un sens pour le professionnel le rend plus enclin à faire confiance et à utiliser l’identité de l’application résultante.
Que signifie « compréhensible » en termes pratiques ?Vous disposez peut-être d’une application, telle que java.exe, où le nom du processus représente l’application en cours d’exécution, mais le binaire java.exe lui-même, qui peut vous donner des informations spécifiques, pourrait être utilisé pour plusieurs applications.
L’un des processus les plus critiques pour lesquels nous utilisons des caractéristiques compréhensibles est de les extraire et de les identifier par rapport aux applications destinées aux professionnels de la sécurité, car la plupart des utilisateurs qui voient un SHA 256 n’auront aucune idée de ce dont il s’agit. En revanche, s’ils voient une application qu’ils connaissent [comme java.exe], ils auront une bien meilleure idée de ce qui se passe sur leur réseau.
Troisième clé de l’identité des applications : grande variété de caractéristiques
Comme mentionné dans la « première clé », l’identité d’une application doit être basée sur une combinaison de nombreux attributs, et pas seulement sur un petit nombre qui pourrait potentiellement être utilisé pour identifier plusieurs applications. Identifier une application sur la base d’un grand nombre d’attributs signifie que certaines parties de l’identité peuvent changer (par exemple, à la suite de mises à jour logicielles) sans que cela ne modifie l’empreinte globale de l’application. Cela reviendrait à identifier une personne en fonction de sa taille, de son groupe sanguin, de son ADN, de son âge (à un moment donné), de la couleur de ses yeux, de la couleur de ses cheveux, du type de vêtements qu’elle porte, de sa façon de parler, de sa façon de marcher, de son lieu de résidence, de ses parents biologiques, etc. Certains de ces éléments peuvent changer, tandis que d’autres sont inévitablement immuables.
L’utilisation d’un échantillon représentatif d’attributs fournit la base de référence pour l’identité de l’application et permet aux administrateurs d’ajouter d’autres caractéristiques plus variables qui décrivent plus en détail l’application sans perdre confiance en l’exactitude et la viabilité de l’identité.
En utilisant une grande variété de caractéristiques, les entreprises peuvent choisir celles qui comprennent la combinaison adéquate de fonctionnalités, ce qui leur permet de procéder aux meilleures généralisations sur l’identité et le comportement de l’application lorsqu’elle communique sur le réseau.
Quatrième clé de l’identité de l’application : tolérance aux mises à niveau
Les empreintes des applications créées doivent être tolérantes aux mises à niveau, afin de permettre l’utilisation de nouvelles versions de logiciels sans devoir revoir les politiques de sécurité à chaque fois qu’un logiciel est corrigé ou mis à niveau.
Voici une excellente illustration de la tolérance aux mises à niveau : si vous mettez Java à niveau, le SHA 256 sera complètement différent, d’une manière imprévisible. Mais le hachage flou sera en grande partie le même parce que le binaire souligné reste en grande partie le même. Cela signifie qu’en utilisant une mesure de similarité par le hachage flou, nous pouvons déterminer quand une application est mise à niveau et quand elle est suffisamment similaire pour pouvoir utiliser les mêmes règles pour la couvrir.
L’utilisation d’une combinaison d’attributs d’identité changeants et immuables est importante car elle permet à l’utilisateur d’effectuer des mises à niveau, de disposer de différentes versions et de créer différentes règles autour d’applications qui sont très similaires plutôt que des binaires extrêmement spécifiques.
Résumé
La sécurité doit rester malléable tout en appliquant le niveau de protection le plus élevé possible. Lorsque la sécurité peut s’adapter à son environnement ou à ses mises à jour (comme les logiciels/applications/services ont coutume de le faire), elle permet à l’entreprise d’évoluer sans sacrifier l’efficacité. La création d’empreintes d’applications à l’aide des quatre clés décrites ici permet aux entreprises d’examiner les parties les plus importantes d’une application/d’un service qui décrivent, de la manière la plus distinctive possible, les applications présentes et qui communiquent entre elles sur le réseau. C’est autour de ces éléments que peuvent être élaborées les politiques de sécurité qui accompagnent l’application (indépendamment de la topologie du réseau), garantissant ainsi que la protection est maintenue au niveau de ce qui en a le plus besoin.
Consultez la fiche technique pour découvrir comment Zscaler Workload Segmentation prend en charge l’identité des applications.
