Chers NetOps : La règle de sécurité zéro s'applique également à vous

Ok, NetOps. Alors que vous automatisez tout et écrivez des scripts de toutes vos forces, il est temps de vous rappeler gentiment les règles de sécurité. Je ne parle pas de pare-feu, de WAF ou d’autres services de sécurité dont vous pourriez être responsable du déploiement et de la gestion. Je parle des scripts et du code que vous allez utiliser lorsque vous vous lancerez dans le voyage qu’est la transformation numérique.

Aujourd’hui, j’aimerais vous rappeler la règle de sécurité zéro. Pour vous rafraîchir la mémoire :

RÈGLE DE SÉCURITÉ ZÉRO : TU NE FERAS PAS CONFIANCE AUX INFORMATIONS DES UTILISATEURS. JAMAIS. 

Une règle assez simple, n’est-ce pas ?

Cela devrait être le cas, mais ce n'est pas le cas. Toute violation dans le monde des affaires peut être attribuée à la violation de la règle de sécurité zéro. Les violations de cette règle sont monnaie courante dans les exemples de code proposés aux développeurs lorsqu'ils recherchent et apprennent de nouveaux langages et frameworks, et malheureusement, elles se glissent également dans le nouveau domaine passionnant qu'est NetOps.

Puis-je présenter la pièce A :

Maintenant, pour être juste, au moins ce script a la décence de vous avertir que les données ne sont pas validées. C’est une bonne chose, car ce script effectue ensuite toutes sortes de manipulations à distance des configurations du routeur en fonction de l’entrée.

Mon problème avec cela est que le code est conçu pour aider à instruire NetOps sur la façon de démarrer avec des scripts pour automatiser les périphériques réseau de production et se contente de hocher la tête vers la validation des données sans fournir aucune information utile sur la façon de procéder.

Pour de bons conseils sur la validation des adresses IP en Python, consultez cette discussion Stack Overflow .

Mais Lori, c'est du script et nous faisons des choses en ligne de commande, alors allez, à quel point est-ce risqué ?

Les mauvaises habitudes sont difficiles à briser.

Ignorer la règle de sécurité zéro pose deux problèmes.

Premièrement, les jours de la CLI sont comptés, mon ami. L'API est la nouvelle CLI, et la plupart des frameworks d'automatisation adoptent l'utilisation d'API RESTful pour provisionner et gérer les périphériques et services réseau. Cela signifie des piles d'applications et des analyseurs. Il s’agit d’appareils potentiellement vulnérables à l’exploitation, car leur configuration peut être modifiée via une API pouvant inclure des vulnérabilités.

Je vous propose comme preuve que je ne suis pas exagéré cet avis de Cisco concernant la vulnérabilité largement évoquée d'Apache Struts. Le consensus consiste à transmettre des entrées non nettoyées au framework Struts, ce qui déclenche toutes sortes de problèmes.  

Mais juste au cas où le potentiel d’exploitation ne vous inciterait pas à vous soucier de l’application de la règle de sécurité zéro, permettez-moi de souligner que l’absence de nettoyage des entrées peut avoir un rayon d’explosion bien plus grand qu’un seul appareil. Considérez ce que nous savons sur la panne d’Amazon S3 au début de 2017 :  

À 9h37 PST, un membre autorisé de l'équipe S3 utilisant un playbook établi a exécuté une commande destinée à supprimer un petit nombre de serveurs pour l'un des sous-systèmes S3 utilisés par le processus de facturation S3. Malheureusement, l’une des entrées de la commande a été saisie de manière incorrecte et un ensemble de serveurs plus grand que prévu a été supprimé.

--Résumé de l'interruption du service Amazon S3 dans la région de Virginie du Nord (US-EAST-1)

Le nombre qu’il a entré dans le script était bien plus grand que prévu. Mais les scripts qui acceptent aveuglément tout ce que l’opérateur propose (en ignorant la règle de sécurité zéro) sont voués à finir par conduire à ce genre d’erreur. Une simple vérification – certes ennuyeuse – du script aurait pu empêcher que le problème ne devienne le sujet de conversation de Twitter pendant plus d’une semaine.

Dans le réseau, en production, nous envisageons souvent la sécurité à travers le prisme de l’autorisation. Bob a-t-il l’autorité d’effectuer cette action ? Alice peut-elle exécuter ce script ? Et nous en avons besoin, c’est toujours essentiel.

Mais à mesure que nous accélérons notre parcours de transformation numérique (interne) et que nous adoptons davantage de frameworks et utilisons des API et des scripts pour automatiser le provisionnement et la gestion, nous devons absolument également prendre en compte la sécurité du point de vue du développement.

Et la première de ces règles est la règle de sécurité zéro : TU NE FERAS PAS CONFIANCE AUX INFORMATIONS DES UTILISATEURS. JAMAIS. 

Validez toujours la saisie. Non seulement cela offre une sécurité supplémentaire, mais cela peut également empêcher une bonne automatisation de mal tourner.