Compréhension de l'examen de site privé

ASoC propose la fonctionnalité Dynamic Application Security Testing (DAST) depuis un scanner cloud tel que SaaS. Cette capacité exige que le scanner cloud puisse accéder à l'application testée. Il est possible d'examiner sans problème des applications Web disponibles au public. Cependant, l'examen de site privé n'est possible qu'après avoir ajouté des composants réseau (tels que des VPN ou des proxy) ou modifié le réseau pour permettre au scanner d'accéder au serveur hôte de l'application Web.

Création de tunnels PSS

Notre solution pour l'examen de site privé (PSS) n'implique aucune modification spéciale au niveau du réseau du client susceptible de présenter un risque pour le réseau. Le client PSS défini dans le réseau du client nécessite uniquement un accès sortant vers Internet (soit directement, soit via un proxy HTTP) et un accès vers le site examiné.

La solution consiste en deux nœuds finaux (serveur et client) qui créent un tunnel TCP/IP initié par le nœud final du côté du client.

Serveur de tunnel

Ce nœud final réside dans le réseau SaaS à côté du scanner. Il est uniquement démarré au démarrage d'un nouvel examen. Le serveur a deux « côtés » qui consistent à écouter les connexions (serveurs dos à dos).

Le premier écoute les connexions entrantes provenant du client du tunnel. Il s'agit du côté tunnel.
Le second écoute les connexions entrantes provenant du scanner. A cette fin, il imite un proxy HTTP. Il s'agit donc du côté proxy.

Lorsque des connexions provenant du client sont disponibles, le scanner envoie les demandes au côté proxy, qui font ensuite l'objet d'une redirection de port vers les connexions entrantes du côté tunnel. Lorsque le client envoie des réponses, elles sont transférées jusqu'au scanner en passant par le côté proxy.

Client de tunnel

Ce nœud final réside dans le réseau du client et génère les connexions TCP/IP vers le serveur. Il remplit la même fonction que le serveur de tunnel, sauf qu'il se compose de deux ensembles de connexions client (clients dos à dos). Le client de tunnel dispose également de deux « côtés ».

Le côté tunnel est un ensemble de connexions initiées vers le serveur de tunnel.
Le côté client est l'ensemble de connexions initiées vers le serveur examiné (directement ou via un proxy).

Le client de tunnel réalise la redirection de port.

AppScan Presence

Le tunnel d'examen de site privé repose sur un mécanisme contrôlé par SaaS appelé AppScan Presence : un canal de communication qui reçoit des tâches à réaliser depuis le service cloud, et qui déclenche la réalisation de ces tâches par des gestionnaires. Le service Presence est un service d'interrogation qui interroge constamment le service cloud à propos de tâches à l'aide d'une communication HTTP sécurisée.

Le service AppScan Presence sert uniquement à extraire des tâches du service SaaS, à télécharger les informations requises pour gérer la tâche et à déclencher le gestionnaire. Dans ce cas, la tâche est gérée pour le client de tunnel et les informations extraites sont les données requises pour le démarrage des connexions du client de création de tunnel jusqu'au serveur.

Réalisation d'un examen

Pour réaliser un examen, il est nécessaire de démarrer le client de tunnel et de le connecter à un serveur. Cette tâche est réalisée par la structure AppScan Presence.

La structure AppScan Presence se compose d'un service Presence qui s'exécute sur la machine du client de tunnel. Le service Presence interroge le serveur SaaS Presence, qui s'exécute sur le cloud et qui indique le moment où un examen est prêt à être exécuté. L'échange entre les services se compose des détails de l'examen, y compris de l'adresse IP du serveur de tunnel auquel le client doit se connecter. En outre, il reçoit des informations qui lui permettent d'identifier positivement le serveur auquel il se connecte. Vous trouverez davantage d'informations dans la section Remarques sur la sécurité ci-après.

Dès qu'un utilisateur a demandé un examen privé et a sélectionné une instance Presence par laquelle l'examen doit être réalisé, un agent d'examen est affecté et le serveur de tunnel de cet agent est démarré. Ensuite, une tâche est mise en file d'attente dans le serveur SaaS. Cette tâche est acceptée par le service Presence, qui lance ensuite un client de tunnel contenant les informations de connexion pertinentes.

Considérations relatives à la sécurité

Deux importants aspects de sécurité sont pris en compte : le réseau du client et la sécurité de la connexion du tunnel.

La solution n'implique aucune modification au niveau du réseau du client. Il est important de noter que l'instance AppScan Presence et le client du tunnel PSS ne nécessitent aucune concession spéciale. Ainsi, le client peut appliquer les stratégies de sécurité organisationnelle sur la machine hôte qui exécute l'instance AppScan Presence et le client du tunnel PSS. Il n'est pas nécessaire de modifier le pare-feu de l'organisation (par exemple, autoriser les connexions entrantes sur certains ports ou certaines adresses IP). Dans la plupart des cas, il n'est pas nécessaire de modifier le pare-feu de l'organisation (par exemple, en autorisant les connexions entrantes sur des ports ou des adresses IP spécifiques). Voici les seules exceptions :

Si les machines ne peuvent pas accéder directement à l'Internet sortant, l'accès de la machine hébergeant AppScan Presence doit être autorisé.
Si l'organisation quitte le trafic SSL/TLS avec son propre certificat, les connexions à AppScan sur Cloud doivent être exclues afin que la communication ne soit pas interrompue et que les mécanismes de sécurité intégrés à l'architecture puissent fonctionner correctement.

Dans ce cas, veillez à ce que les plages d'adresses IP utilisées par ASoC soient exclues de la désinscription, ou autorisez un accès direct à ces plages et vérifiez qu'elles ne sont pas bloquées par votre pare-feu.

ID Presence

Chaque service Presence dispose d'une clé unique qui lui sert d'ID. Elle sert à identifier l'instance Presence et à lui fournir les tâches d'examen correctes. Il est possible de renouveler la clé à tout moment, pour ainsi se conformer aux règles de sécurité organisationnelle qui exigent des mises à jour périodiques. Dès qu'une clé est renouvelée sur le serveur, l'instance Presence cesse de recevoir des tâches jusqu'à ce que la clé soit physiquement placée sur la machine Presence.

Authentification

Il est essentiel que le serveur de tunnel et le client de tunnel puissent compter l'un sur l'autre, afin de prévenir tout accès extérieur au réseau privé depuis un emplacement non validé. Lorsqu'un examen est prêt à être exécuté et que le serveur de tunnel est démarré, il génère une clé de serveur privée et un certificat, ainsi qu'une clé client aléatoire (25 caractères alphanumériques). Le certificat du serveur et la clé client sont transmis au client de tunnel avec les détails de la tâche d'examen (via la communication entre le service Presence et le service SaaS). Le serveur et le client de tunnel peuvent ensuite valider l'identité de la connexion à distance.

Le certificat du serveur et la clé client sont invalidés dès que l'examen est terminé et ne sont plus réutilisés, même dans le cas d'un nouvel examen.

Le certificat est conforme aux dernières normes NIST et FIPS qui sont mises à jour occasionnellement (algorithme de chiffrement, algorithme de hachage et longueur de clé).

Protection des données en transit

La connexion tunnel est chiffrée à l'aide de TLS 1.2. Le client de tunnel obtient le certificat de serveur ad hoc à l'avance et l'utilise pour vérifier que le certificat serveur utilisé dans l'authentification TLS est le certificat attendu. Une fois que le client a authentifié le serveur, il envoie la clé du client au serveur, de sorte que le serveur puisse authentifier le client. Les données passées à travers ce tunnel sont composées des requêtes et réponses entre le scanner et l'application de test, et sont donc sensibles. Pour protéger les données, ces dernières sont cryptées en transit entre les extrémités du tunnel à l'aide de ce certificat et de ces clés à exécution unique.