Applications informatiques sécuritaires à 100% : un aperçu

Le 19 février 2014, je donnais une conférence pour l’OWASP sur le sujet. Voici la suite logique et plus complète. Cet article est un aperçu d’un chapitre d'un livre à paraître...J'en publie une partie pour répondre partiellement à la question de Stéphane Garneau sur la microsegmentation de la sécurité d'une application...

De façon irréaliste, la meilleure sécurité est de déployer l'application sur un serveur qui va être coulé dans un bloc de béton conservé à Fort Knox et qui n’a jamais été branché sur un réseau. L’accès se fait en mode interactif sur place et est surveillé par une personne indépendante!

La solution réaliste réside dans une sécurité multicouche sans aucune confiance (principe de Kerckhoffs : The enemy knows the system!). Cette sécurité pourrait offrir une étanchéité de 100% avec, vraisemblablement, une confidentialité persistante (forward security) à l’exception des responsabilités propre à l’utilisateur.

Dix étapes à implanter!

Premièrement, toutes les applications doivent être découpées en micro/miniservices (12-factor app, particulièrement le #7) avec toutes les préoccupations de sécurité sorties complètement des applications, une sorte d’AOP extrême. Toutes les préoccupations horizontales suivantes sont activées systématiquement pour tous les micro/miniservices, sans aucune exception.

• authentification à plusieurs facteurs (identification par témoin et adresse IP pour les services anonymes),
• autorisations RBAC et ABAC (particulièrement sur les occurrences),
• journalisation (voir plus bas),
• passage des contextes de sécurité n-hop et n-couches de découpage qui suit le principe de Kerckhoffs (le jeton ne doit que contenir une clé non descriptive),
• sécurisation complémentaire n-hop par certificats clients/serveurs uniques sous une seule autorité de certification pour chacun des containers,
• throttling (authentification et requêtes),
• limites sur la taille des chargement (payload),
• dégradation élégante et élasticité en cas de DDOS.

Deuxièmement, il faut protéger toutes les couches ou services réseau avec plusieurs appareils de technologie différentes :

• 802.1x avec certificats pour tous les appareils et découpage des zones réseau par VLAN (couche OSI 2),
• pare-feu plein état avec whitelisting restrictifs et découpage du périmètre de sécurité par des règles de routage basées par DDNS sécuritaire des exécuteurs de containers (couches OSI 3 (IP), 4 et 5 (TCP)),
• TLS 1.3 obligatoire avec utilisation exclusive d’algorithmes offrant une confidentialité persistante (ex : ECDHE) par des serveurs mandataires inversés redondants qui redirigent dynamiquement les requêtes vers les bons micro/miniservices selon des règles de distributivité définies par le gestionnaire de containers (couche OSI 6),
• analyse complète par pattern de tous les messages (entête et chargement) par whitelisting extrêmement restrictifs pour les micro/miniservices (couche OSI 7 (ex. : WAF)).

Troisièmement, sécurisation par un dépôt approprié de tous les fichiers et données pour que leur exécution soit impossible. L’utilisation d’espace réservé en mémoire pour les données en transit est nécessaire (bit NX).

Quatrièmement, construction/déploiement du container signé par une serveur de construction à partir de code source contenu dans un gestionnaire de source dont tout le code archivé a été revu systématiquement par une autorité indépendante et incorruptible. Des essais (audits, PEN et autres) sont aussi réalisés automatiquement à chacun des déploiement dans un environnement en tout point identique à la production. Le code source comprend aussi toute la configuration des appareils qui doit passer aussi par le gestionnaire de source et les revues (infrastructure as code). Ainsi, pour configurer un appareil ou un service, il n’est jamais nécessaire pour un administrateur de détenir le mot de passe dudit appareil ou service (voir plus loin).

Cinquièmement, surveillance automatisée (IPS/IDS) de toutes les couches précédentes accompagnée d’une mise hors service (coupure du lien) en cas de pénétration et alertage en temps réel. Il est préférable de rendre une application non disponible que de la laisser à la merci d’utilisateurs malveillants.

Sixièmement, aucune utilisation d’appareils ou services qui ne sont pas à code source ouvert et qui n'ont pas fait l'objet d'une analyse/revue du code et d’audits par une tierce partie indépendante.

Septièmement, tous les mots de passe et clés des compte de services et des appareils doivent être différents en plus d’être générés de façon totalement aléatoire. La génération des clés est réalisée dans un lieu sûr par le maître des clés qui est sous surveillance. Le maître des clés doit, par la suite, utiliser ou déployer le mot de passe à l’endroit prévu, une seule fois, et détruire toute copie. Si on a besoin d'avoir accès à un service ou appareil, on le change physiquement ou virtuellement (on peut le recycler, bien sûr). Ça revient à formater le serveur ou changer physiquement un routeur pour un autre! Bien entendu, il s’agit de clés ou mots de passe servant comme comptes de service ou d’administrateur d’appareils physiques/virtuels.

Huitièmement, tous les appareils sont dans un endroit physique hautement sécurisé et sous haute surveillance en plus d'être géographiquement distribués et avec plusieurs liens réseau physiques. Dans un monde idéal, les appareils n’ont aucun ports externes sauf pour l’alimentation électrique et le réseau.

Neuvièmement, journalisation complète des accès, des erreurs et des anomalies détectée avec réplication instantanée.

Dixièmement, classification complètes des tous les actifs informationnels. Toutes les données déclarées secrètes doivent être systématiquement cryptées. Les index sur ces données sont inexistants ou désincarnés. Par ailleurs, toutes les écritures sont versionnées sur des supports WORM répliqués et distribués géographiquement. Cela remplace avantageusement toutes les copies de sécurité imaginables,

Il existe plusieurs préoccupations quant à l’implantation de toutes ces mesures. Quelques exemples :

• Les progiciels doivent suivre toutes les même règles qu’un développement maison.
• La latence sur le réseau pourrait devenir importante. Il existe plusieurs façons de s'en sortir : antémémoire, distributivité, ne pas lésiner sur la capacité des appareils.
• Le développement risque de devenir plus long. Il faut donc implanter rapidement les mécanismes d’intégration continue, le TDD/BDD, l’hébergement en mode PaaS, etc.
• Plusieurs fournisseurs d’appareils réseau et de sécurité ne se qualifient plus. De toute façon, si on suit le corollaire du principe de Kerckhoffs, pourquoi devrait-on faire confiance en des boîtes noires? Nous avons qu’à penser aux algorithmes de cryptographie.
• Les coûts pourraient être exorbitants. C’est le cas quand on tient compte des applications patrimoniales qui seraient, de toute façon, à repenser. Cependant, si la sécurité multicouche précédente est mise en application dès le début d’un développement, les coûts deviennent plus que raisonnables.

À la suite de la publication de cet article, je m’attends à beaucoup de réactions, voir de résistance de la part de mes amis en sécurité. Cependant, si vous distillez son contenu, il est facile de voir que la solution tient en quelques principes simples avec lesquels vous êtes d’accord :

• La sécurité est une préoccupation horizontale et systématique. Elle est l’affaire de tous.
• On ne doit faire confiance à personne, même à nous-même.
• Plus le secret est gros, plus il est difficile à conserver.
• L’approche par blacklisting est à bannir. Il va toujours avoir de nouveaux vecteurs d’attaque. N’en déplaise à mes amis développeur qui prennent trop souvent des raccourcis, il faut être intraitable sur la sécurité. L’utilisation du whitelisting force à faire les bonnes choses, tout le temps.
• L’utilisateur restera toujours le maillon le plus faible de la chaîne car on doit lui offrir des services sans jamais lui nuire inopinément. Des essais d’utilisabilité sont toujours nécessaire pour arriver à un niveau de sécurité juste suffisant. Mais on ne doit pas décharger pour autant l’utilisateur de son imputabilité face à la sécurité.
• La sécurité ne passe pas par la technologie mais par des pratiques.

J’attends vos commentaires!