Ingénierie chez Barracuda

L'histoire de Barracuda Active Threat Intelligence

Il y a quelque temps, lors d'une de nos sessions de brainstorming, pendant laquelle les équipes ont discuté du prochain niveau d'évolution de nos produits, il est devenu évident qu'une analyse poussée des données à grande échelle serait nécessaire pour détecter les menaces modernes et émergentes, et s'en prémunir. Il fallait que cette analyse anticipe les risques encourus par les clients, et ce, de manière rapide et efficace afin de bloquer toute action malveillante.

En analysant les exigences, nous avons constaté que pour fournir une protection contre les pirates avancés comme les bots, nous devions créer une plateforme capable d'analyser le trafic des sessions Web, de le corréler avec les données de toutes les sessions, et ce, pour de nombreuses choses, dans l'ensemble de la base de clients. Nous avons également observé que de nombreuses parties du système devaient être en temps réel, d'autres en temps quasi réel et que d'autres encore pouvaient avoir une phase d'analyse beaucoup plus longue.

Il y a quelques années, nous avons lancé Barracuda Advanced Threat Protection (BATP) pour la protection contre les attaques de malwares de type zero-day dans la gamme de produits Barracuda. Cette fonctionnalité (qui en plus du sandboxing, analyse les fichiers pour détecter les malware à l'aide de plusieurs moteurs) a été ajoutée dans les produits de sécurité des applications de Barracuda pour sécuriser des applications telles que les systèmes de traitement des commandes où les fichiers sont téléchargés par des tiers. Il s'agissait de la première tentative d'utilisation d'une couche cloud pour effectuer une analyse avancée qu'il aurait été difficile d'intégrer dans des appliances Web Application Firewall.

Bien que la couche cloud BATP puisse gérer des millions d'analyses de fichiers, nous avions besoin d'un système capable de stocker une quantité importante de métadonnées afin de les analyser et détecter les menaces modernes et évolutives. Cela fut une première étape vers la création de la prochaine plateforme de suivi des menaces.

Comment fonctionne le suivi actif des menaces

La plateforme de suivi actif des menaces de Barracuda est notre solution au problème. Cette plateforme repose sur un gigantesque data lake, qui peut gérer le traitement des flux et le traitement par lots de données. Elle traite des millions d'événements par minute dans toutes les régions du monde, et fournit des renseignements utilisés pour détecter les bots et les attaques côté client, ainsi que des informations pour se protéger contre ces vecteurs de menace. Le suivi actif des menaces de Barracuda est conçu avec une architecture ouverte capable d'évoluer rapidement pour répondre aux nouvelles menaces.

Aujourd'hui, la plateforme de suivi actif des menaces de Barracuda reçoit des données des moteurs de sécurité du Web Application Firewall et du WAF-as-a-Service de Barracuda, ainsi que d'autres sources. Lorsqu'ils sont reçus, les événements sont complétés par des flux de menaces obtenus par crowdsourcing et d'autres bases de données de renseignements. L'analyse détaillée de ces événements, à la fois individuellement et dans le cadre d'une session utilisateur, permet de classer les clients en tant qu'êtres humains ou bots.

Les pipelines d'analyse des données utilisent divers moteurs et modèles de machine learning pour analyser les multiples aspects du trafic et formuler leurs recommandations, qui sont ensuite réconciliées pour produire le verdict final.

Les façons dont le suivi actif des menaces contribue à protéger vos applications

En plus de prendre en charge toutes les analyses requises pour Advanced Bot Protection, la plateforme de suivi actif des menaces est utilisée dans nos dernières offres : la protection côté client et le moteur de configuration automatisé.

Le suivi actif des menaces concerne toutes les ressources externes pouvant être utilisées par l'application, comme un JavaScript externe ou une feuille de style. Le suivi des ressources externes nous permet de connaître la surface des menaces et de fournir une protection contre des attaques comme Magecart, entre autres.

Les métadonnées collectées étant extrêmement riches, nous pouvons en tirer des informations supplémentaires pour aider les administrateurs en leur fournissant des recommandations de configuration basées sur le trafic réel arrivant sur leurs applications.

Cette plateforme a joué un rôle essentiel dans le développement des fonctionnalités de protection nouvelle génération dont nos clients ont besoin. Nous continuons de tirer parti de cette plateforme évolutive pour recueillir des informations détaillées sur les modèles de trafic, l'utilisation des applications, et plus encore. Ne manquez pas les articles de blog de nos équipes d'ingénierie qui vous expliqueront comment nous avons développé le suivi actif des menaces de Barracuda.

Anshuman Singh

Anshuman Singh est directeur senior de la gestion des produits chez Barracuda. Connectez-vous avec lui sur LinkedIn ici.

www.barracuda.com

Enregistrement d'événements à grande échelle sur AWS

La plupart des applications génèrent des événements de configuration et d'accès, que les administrateurs doivent pouvoir visualiser. Le service Barracuda Email Security offre une plus grande transparence et visibilité sur tous ces événements pour aider les administrateurs à ajuster et comprendre leur système. Il vous permet notamment de connaître l'identité des utilisateurs connectés à un compte ainsi que le moment où ils se connectent ou encore d'identifier la personne qui a ajouté, modifié ou supprimé la configuration d'une politique spécifique.

Développer un tel système distribué et interrogeable requière de se poser plusieurs questions, parmi lesquelles :

• Comment extraire ces enregistrements de l'ensemble de vos applications, services et machines pour les envoyer vers un emplacement centralisé ?
• Quel doit être le format standard de ces fichiers journaux ?
• Combien de temps devrez-vous conserver ces journaux ?
• Comment relier les événements provenant de différentes applications ?
• Comment proposer à l'administrateur un mécanisme de recherche à la fois simple et rapide, accessible depuis une interface utilisateur ?
• Comment permettre l'accès à ces journaux via une API ?

Elasticsearch est la première solution qui nous vient à l'esprit lorsque l'on pense à un moteur de recherche distribué. Hautement évolutif, il permet une recherche en temps quasi réel et est disponible en tant que service entièrement géré via AWS. Pour cet exemple, nous allons donc enregistrer nos journaux d'événements dans Elasticsearch, et Kinesis Data Firehose assurera leur transfert depuis les différentes applications jusqu'à notre moteur de recherche.

Les composants de cette architecture

1. Kinesis Agent – Kinesis Agent d'Amazon est une application logicielle Java autonome qui vous permet de collecter et d'envoyer facilement des données vers Kinesis Data Firehose. Cet agent assure un suivi continu des fichiers journaux d'événements dans les instances EC2 Linux et les transfère vers le flux de diffusion Kinesis Data Firehose configuré. L'agent gère ainsi la rotation des fichiers, les points de contrôle et les nouvelles tentatives après échec pour vous fournir toutes les données dont vous avez besoin de manière fiable, rapide et simple. Notez toutefois qu'un conteneur Fluentd sera nécessaire si l'application qui doit écrire dans Kinesis Firehose est un conteneur Fargate. Cependant, cet article se concentre sur les applications exécutées sur des instances Amazon EC2.
2. Kinesis Data Firehose – La méthode Direct PUT d'Amazon Kinesis Data Firehose permet d'écrire des données au format JSON dans Elasticsearch, sans qu'aucune donnée ne soit stockée dans le flux.
3. S3 – Un compartiment S3 peut être utilisé pour sauvegarder la totalité des enregistrements ou seulement ceux dont l'envoi vers Elasticsearch a échoué. Il est également possible de créer des politiques de cycle de vie afin d'automatiser l'archivage des journaux.
4. Elasticsearch – Elasticsearch hébergé par Amazon. L'accès à Kibana peut être activé afin de simplifier la requête et la recherche de journaux à des fins de débogage.
5. Curator – AWS recommande d'utiliser Lambda et Curator pour gérer les index et instantanés du cluster Elasticsearch. De plus amples informations et un exemple de code sont proposés par AWS ici.
6. Interface API REST – Vous pouvez créer une API qui fera office de couche d'abstraction pour Elasticsearch tout en s'intégrant parfaitement à l'interface utilisateur. Les architectures de microservices par API sont réputées pour leurs performances élevées, notamment en matière de sécurité et de conformité, ainsi que pour leur intégration optimale avec d'autres services.

Évolutivité

• Kinesis Data Firehose : par défaut, les flux de diffusion Firehose peuvent traiter jusqu'à 1 000 enregistrements par seconde ou 1 Mio par seconde dans la région USA Est (Ohio). Cette limite n'est toutefois pas stricte et peut être étendue jusqu'à 10 000 enregistrements par seconde. Ce nombre varie en fonction des régions.
• Elasticsearch : les capacités de stockage et la puissance de calcul du cluster Elasticsearch peuvent être étendues dans AWS. Des mises à niveau sont également disponibles. Amazon ES fait appel à un flux de déploiement Blue-Green pour la mise à jour des domaines. Par conséquent, le nombre de nœuds contenus dans le cluster est susceptible de croître temporairement lorsque des modifications sont appliquées.

Les avantages de cette architecture

1. L'architecture de pipeline est entièrement gérée, demandant très peu de maintenance.
2. En cas d'échec du cluster Elasticsearch, Kinesis Firehose peut conserver les enregistrements pendant 24 heures. En outre, les enregistrements qui ne peuvent pas être transmis sont également sauvegardés dans S3.

Les risques de perte de données sont ainsi moindres.

3. Les politiques de gestion des identités et des accès (IAM) permettent un contrôle strict des accès aux API Kibana et Elasticsearch.

Les limites

1. La question du tarif doit être soigneusement étudiée et surveillée. Kinesis Data Firehose est capable d'absorber sans difficulté de larges volumes de données et si un acteur non autorisé commence à journaliser un grand nombre de données, le service les diffusera. Attention, les frais occasionnés peuvent être élevés.
2. L'intégration Kinesis Data Firehose vers Elasticsearch est uniquement compatible avec les clusters Elasticsearch non VPC.
3. Kinesis Data Firehose ne prend actuellement pas en charge la diffusion de journaux vers des clusters Elasticsearch non hébergés par AWS. Cette configuration n'est pas non plus compatible avec l'auto-hébergement de clusters Elasticsearch.

Conclusion

Si vous êtes en quête d'une solution entièrement gérée et capable d'évoluer sans que vous n'ayez à intervenir (ou très peu), cette option est tout à fait adaptée. Le backup automatique sur S3 et les politiques de cycle de vie apportent, de plus, une réponse simple à la question de la conservation et de l'archivage des journaux.

Sravanthi Gottipati

Sravanthi Gottipati est responsable de l'ingénierie pour la sécurité des e-mails chez Barracuda Networks. Vous pouvez vous connecter avec elle sur LinkedIn ici.

www.barracuda.com

DJANGO-EB-SQS : la communication entre les applications Django et AWS SQS devient un jeu d'enfant

Les services AWS comme Amazon ECS, Amazon S3, Amazon Kinesis, Amazon SQS et Amazon RDS sont fréquemment exploités dans le monde entier. Chez Barracuda, nous utilisons AWS Simple Queue Service (SQS) pour gérer la messagerie au sein et parmi les microservices que nous avons développés sur le cadre Django.

AWS SQS est un service de gestion des messages en attente qui permet « d'envoyer, de stocker et de recevoir des messages entre des composants logiciels, quel que soit le volume, sans risque de perdre des messages ou de nécessiter le recours à d'autres services. » SQS est conçu pour aider les entreprises à dissocier les applications et à faire évoluer les services, et c'était l'outil idéal pour nos projets portant sur les microservices.  Cependant, chaque nouveau microservice basé sur Django ou la dissociation d'un service existant à l'aide d'AWS SQS exigeait que nous dupliquions notre code et notre logique pour communiquer avec AWS SQS. Cela a donné lieu à de nombreuses répétitions de code et a motivé notre équipe à créer cette bibliothèque GitHub : DJANGO-EB-SQS

La bibliothèque python Django-EB-SQS a été conçue pour aider les développeurs à intégrer rapidement AWS SQS avec des applications existantes et/ou nouvelles basées sur Django. La bibliothèque se charge des tâches suivantes :

• Sérialisation des données
• Ajout d'une logique de report
• Vérification de la file d'attente en permanence
• Désérialisation des données conformément aux normes AWS SQS et/ou utilisation de bibliothèques tierces pour communiquer avec AWS SQS.

En bref, il fait abstraction de toute la complexité liée à la communication avec AWS SQS et permet aux développeurs de se concentrer uniquement sur la logique commerciale principale.

La bibliothèque est basée sur le cadre Django ORM et la bibliothèque boto3.

Comment nous l'utilisons

Notre équipe travaille sur une solution de protection des e-mails qui utilise l'intelligence artificielle pour détecter le spear phishing et d'autres attaques de Social Engineering. Nous nous intégrons au compte Office 365 de nos clients, qui reçoivent des notifications dès qu'ils reçoivent de nouveaux e-mails. L'une des tâches consiste à déterminer si le nouvel e-mail est exempt de toute possibilité de fraude ou non. À la réception de ces notifications, l'un de nos services (Figure 1 : Service 1) communique avec Office 365 via Graph API et reçoit ces e-mails. Pour le traitement ultérieur de ces e-mails et pour rendre les e-mails accessibles à d'autres services, ces e-mails sont ensuite transférés vers la file d'attente AWS SQS (Figure 1 : queue_1).

Figure 1

Examinons un cas d'utilisation simple sur la façon dont nous utilisons la bibliothèque au sein de nos solutions. L'un de nos services (Figure 1 : Service 2) est chargé d'extraire les en-têtes et les ensembles de fonctionnalités des e-mails individuels et de les mettre à la disposition des autres services.

Le service 2 est configuré pour surveiller la queue_1 afin de récupérer les corps bruts des e-mails.

Supposons que le Service 2 effectue les actions suivantes :

# consomme les e-mails de la queue_1

…

# extrait les en-têtes et les ensembles de fonctionnalités des e-mails

…

# soumet une tâche

process_message.delay(tenant_id=, email_id=, headers=, tenant_id=, feature_set=, ….)

Cette méthode process_message ne sera pas sollicitée de manière synchrone, elle sera placée en attente en tant que tâche et sera exécutée dès que l'un des employés la traitera. L'employé peut appartenir au même service ou à un service différent. Le commanditaire de la méthode n'aura pas à se soucier du comportement sous-jacent et de la manière dont la tâche sera exécutée.

Voyons comment définir la méthode process_message comme une tâche.

depuis le fichier d'importation de tâches eb_sqs.decorators

@task(queue_name='queue_2′, max_retries=3)
def process_message(tenant_id: int, email_id: str, headers: List[dict], feature_set: List[dict], …) :

essayer :

# exécute une action en utilisant des en-têtes et des ensemble de fonctionnalités
# peut également mettre d'autres tâches en file d'attente, si nécessaire

sauf(OperationalError, InterfaceError) comme exc :

essayer :

process_message.retry()

sauf MaxRetriesReachedException :

logger.error(‘MaxRetries reached for Service2:process_message ex: {exc}')

Lorsque nous décorons la méthode avec le décorateur de tâche, ce qui se passe ensuite est qu'il ajoute des données supplémentaires comme la méthode appelante, la méthode cible, ses paramètres et quelques métadonnées supplémentaires avant de sérialiser le message et de le transférer vers la file d'attente AWS SQS. Lorsque le message est extrait depuis la file d'attente par l'un des employés, il dispose de toutes les informations nécessaires à l'exécution de la tâche : quelle méthode appeler, quels paramètres utiliser, etc.

Nous pouvons également relancer la tâche si une exception survient. Toutefois, pour éviter un scénario sans fin, nous pouvons définir un paramètre facultatif max_retries qui nous permet de suspendre le traitement après avoir atteint le nombre maximal de tentatives. Nous pouvons alors consigner l'erreur ou envoyer la tâche dans une file d'attente de lettres mortes pour une analyse plus poussée.

AWS SQS offre la possibilité de retarder le traitement du message jusqu'à 15 minutes. Nous pouvons ajouter une fonctionnalité similaire à notre tâche en précisant le paramètre de retard :

process_message.delay(email_id=, headers=, …., delay=300) # retard de 5 minutes

L'exécution des tâches peut être effectuée en exécutant la commande Django process_queue. Cela permet de gérer l'écoute d'une ou de plusieurs files d'attente, de les consulter en permanence et d'exécuter les tâches au fur et à mesure qu'elles arrivent :

python manage.py process_queue –files d'attente

Nous venons de découvrir comment cette bibliothèque facilitait la communication au sein d'un service ou entre des services via les files d'attente AWS SQS.

Pour plus de détails sur la configuration de la bibliothèque avec les paramètres Django, la possibilité de gérer plusieurs files d'attente, la configuration du développement et bien d'autres fonctionnalités, cliquez ici.

Contribuer

Si vous souhaitez contribuer au projet, veuillez vous rendre ici : DJANGO-EB-SQS

Rohan Patil

Rohan Patil est ingénieur logiciel principal chez Barracuda Networks. Il travaille actuellement sur Barracuda Sentinel, une solution de protection basée sur l'IA contre le phishing et le piratage de compte. Il a travaillé ces cinq dernières années sur les technologies cloud et ces dix dernières années, il a occupé divers postes dans le domaine du développement de logiciels. Il est titulaire d'un master en informatique de l'Université d'État de Californie et d'un bachelor en informatique de Mumbai, en Inde.

Connectez-vous avec Rohan sur LinkedIn ici.

www.barracuda.com

Créer des API robustes et flexibles avec GraphQL

La conception des API est un domaine dans lequel il peut y avoir beaucoup de conflits entre les développeurs d'applications clientes et les développeurs backend. Les API REST nous ont permis de concevoir des serveurs sans statut et un accès structuré aux ressources pendant plus de deux décennies, et elles continuent de répondre aux besoins du secteur, principalement en raison de leur simplicité et de leur courbe d'apprentissage modérée.

REST a été développé aux alentours de l'an 2000, lorsque les applications client étaient relativement simples et que les évolutions n'étaient pas aussi nombreuses qu'aujourd'hui.

Avec une approche traditionnelle basée sur REST, la conception serait basée sur un concept de ressources gérées par un serveur donné. Ensuite, nous nous appuyons généralement sur des verbes HTTP tels que GET, POST, PATCH, DELETE pour effectuer des opérations CRUD sur ces ressources.

Depuis les années 2000, bien des choses ont changé :

• L'utilisation accrue d'applications à page unique et d'applications mobiles a créé un besoin de téléchargement efficace des données.
• De nombreuses architectures backend ont délaissé les architectures monolithiques au profit d'architectures µservice pour des cycles de développement plus rapides et plus performants.
• Une grande variété de clients et de consommateurs sont nécessaires pour les API. REST rend difficile la construction d'une API prenant en charge plusieurs clients, car elle renverrait à une structure de données fixe.
• Les entreprises souhaitent déployer des fonctionnalités plus rapidement sur le marché. Si une modification doit être effectuée côté client, elle nécessite souvent un ajustement côté serveur avec REST, ce qui se traduit par des cycles de développement plus lents.
• L'attention accrue portée à l'expérience utilisateur conduit souvent à la conception de vues/widgets dont le rendu nécessite des données provenant de plusieurs serveurs de ressources API REST.

GraphQL comme alternative à REST

GraphQL est une alternative moderne à REST qui vise à remédier à plusieurs faiblesses. Son architecture et ses outils sont conçus pour offrir des solutions aux pratiques contemporaines de développement de logiciels. Elle permet aux clients de spécifier exactement les données dont ils ont besoin et permet d'extraire des données de plusieurs ressources en même temps. Elle fonctionne davantage comme un RPC, avec des requêtes et des mutations nommées et non des actions obligatoires classiques basées sur le protocole HTTP. Le contrôle est ainsi exercé conformément aux attentes, le développeur de l'API backend spécifiant ce qui est possible, et le client/consommateur de l'API spécifiant ce qui est requis.

Voici un exemple de requête GraphQL, qui a suscité un vif intérêt de ma part lorsque je l'ai découverte. Supposons que nous construisions un site de microblogging et que nous ayons besoin de faire une requête pour 50 messages récents.

query recentPosts(count: 50, offset: 0) {
id
title
tags
content
author {
id
name
profile {
email
interests
}
}
}

La requête GraphQL ci-dessus vise à demander :

• 50 articles récents
• Id, titre, balises et contenu de chaque article de blog
• Informations sur l'auteur incluant l'identifiant, le nom et les informations sur le profil.

Si nous devions utiliser une approche traditionnelle d'API REST pour cela, le client devrait effectuer 51 requêtes. Si les articles et les auteurs sont considérés comme des ressources distinctes, il faudrait une requête pour accéder à 50 articles récents, puis 50 requêtes pour obtenir les informations sur les auteurs de chaque article. Si les informations sur l'auteur peuvent être incluses dans les informations sur l'article, cela pourrait être une requête avec l'API REST également. Mais, dans la plupart des cas, lorsque nous modélisons nos données à l'aide des meilleures pratiques de normalisation des bases de données relationnelles, nous gérons les informations sur les auteurs dans un tableau distinct, ce qui implique que les informations sur les auteurs constituent une ressource API REST distincte.

Ce qui est intéressant avec GraphQL. Supposons que, sur un écran mobile, nous n'ayons pas assez de place pour afficher à la fois le contenu de l'article et les informations sur le profil de l'auteur. Cette requête pourrait être la suivante :

query recentPosts(count: 50, offset: 0) {
id
title
tags
author {
id
name
}
}

Le client sur le mobile spécifie maintenant les informations qu'il désire, et l'API GraphQL fournit les données exactes qu'il a demandées, ni plus ni moins. Nous n'avons pas eu à effectuer d'ajustements côté serveur, ni à modifier de manière significative notre code côté client, et le débit du réseau entre le client et le serveur reste optimal.

Ce qu'il faut retenir ici, c'est que GraphQL nous permet de concevoir des API flexibles en fonction des exigences du client et non pas du point de vue de la gestion des ressources du serveur. La croyance générale est que GraphQL n'a de sens que pour les architectures complexes impliquant plusieurs dizaines de µservices. C'est vrai dans une certaine mesure, étant donné que l'on observe une certaine courbe d'apprentissage avec GraphQL par rapport aux architectures d'API REST. Mais cela tend à changer, grâce à un investissement intellectuel et financier important de la part de la fondation émergente neutre vis-à-vis des fournisseurs.

Barracuda est l'un des premiers à adopter les architectures GraphQL. Si ce billet a suscité votre intérêt, je vous invite à suivre mes prochains billets où je me pencherai sur les détails techniques et les avantages architecturaux.

Vinay Patnana

Vinay Patnana est le directeur technique du service de sécurité des e-mails de Barracuda. À ce poste, il participe à la conception et au développement des services d'évolutivité des solutions pour messagerie de Barracuda.

Vinay est titulaire d'un master en informatique de l'Université d'État de Caroline du Nord et d'un bachelor en ingénierie du BIT Mesra, en Inde.  Il travaille chez Barracuda depuis plusieurs années et compte plus d'une dizaine d'années d'expérience à son actif sur plusieurs variétés de piles techniques.  Vous pouvez le retrouver sur LinkedIn ici.

www.barracuda.com