Nous utilisons des cookies pour vous offrir la meilleure expérience sur notre site web. Si vous continuez à utiliser ce site, nous supposerons que vous en êtes satisfait.

<p>Restons en contact !<br>Recevez notre newsletter trimestrielle en inscrivant votre e-mail.</p>

usecaseBG.jpg

Use Case

Présentation  des Use Case  NANO Corp

Brochure-deep-observability.pdf

Deep Observability.png

Deep Observability

Brochure-smart-alerting.pdf

Smart Alerting.png

Smart Alerting

Brochure-live-forensics.pdf

LiveForensic.png

Live Forensics

Brochure-n.Scope-NDR.pdf

Scope NDR.png

n.Scope NDR

L’article [Explosion des débits : quelle puissance nécessaire pour les superviser demain ?](https://www.nanocorp.fr/explosion-des-debits-quelle-puissance-necessaire-pour-superviser-les-reseaux-de-demain/) abordait le fait que la parallélisation du calcul inhérente au hardware (cartes réseau et processeurs) apportait une réponse pertinente à la course aux débits. Mais elle laissait ouverte la question de la conservation de l’unicité des sessions dans ce processus de parallélisation.

# Complexification des réseaux et encapsulation
Le premier problème auquel un réseau doit répondre est d’assurer un routage efficace et rapide. Ainsi, pour mieux exploiter les opportunités offertes par les débits actuels, les opérateurs (_TELCO_, _FAI_, _data centers_, etc.) utilisent des routeurs disposant de nouvelles capacités telles que la gestion du  **tunneling**. Le routage optimisé permet une convergence et une virtualisation supérieure des réseaux. Il offre alors une amélioration tant de la qualité de service que de la sécurité des réseaux en séparant logiquement le réseau en plusieurs entités.

Le tunneling consiste à **insérer des protocoles** pour simplifier la gestion des réseaux en encapsulant les données vers de nouvelles couches de routage.

# Quid du suivi de la qualité de service et de la sécurité ?
Conçues avant l’utilisation massive du tunnelling, les sondes d’analyse protocolaire employées pour la supervision des réseaux se contentent de traiter uniquement les **enchaînements protocolaires** simples à partir de la **couche IP**. Elles n’avaient pas d’intérêt particulier à traiter les protocoles de bas niveau.

Pour ces sondes classiques, les difficultés sont apparues lorsqu’il s’est agi de traiter les **protocoles situés avant la couche IP**. En effet, l’explosion du tunneling a engendré des problèmes de conservation de l’unicité des sessions lors de la parallélisation des traitements. Afin de contourner ce problème, les sondes classiques ont développé des solutions software et hardware pour accéder à la couche IP en s’affranchissant du tunnelling. La conséquence directe a été de les rendre aveugles aux protocoles de la couche 2 et de prendre le risque de manquer certaines informations cruciales.

# S’affranchir d’une analyse au niveau du tunnelling : quels risques ?
Etre capable d’analyser les protocoles de niveau bas et notamment le protocole de routage est particulièrement important pour s’assurer de la qualité des données en transit, de la bonne configuration des équipement* et de manière générale, de la _bonne santé du réseau_.

Aujourd’hui, il n’est pas possible de garantir pleinement qualité de service et sécurité sans superviser aussi les protocoles de niveau bas que s’échangent les équipements d’un réseau. En passant outre, le **réseau** se retrouve à la merci de la configuration initiale des équipements, seul élément de contrôle mis en œuvre. Si ces équipements n’ont pas été bien configurés, ou s’ils ont été corrompus par une attaque ou une mise à jour malheureuse, il faut alors attendre que les conséquences sur le réseau soient suffisamment visibles pour en constater le dysfonctionnement.

Ne traiter ces enjeux d’analyse de protocole qu’à partir de l’IP et ne pas regarder ce qui se passe en dessous du niveau 3 deviennent aujourd’hui des erreurs aux conséquences graves puisqu’elles reviennent à se **priver à la fois d’une vision de l’encapsulation (perte de granularité), mais également des protocoles dédiés à la gestion du réseau**.

# Les sondes « nouvelle génération » : alliées indispensables pour une supervision efficace
La confiance n’excluant pas le contrôle, il est indispensable de vérifier la bonne configuration des réseaux. Avec des sondes en mesure d’exploiter des **protocoles de niveau bas**, il devient alors possible de disposer d’une cartographie réelle du **routage du réseau** et non pas d’une cartographie théorique alignée sur les configurations des machines. Par exemple, en cas d’anomalie, ce type de sondes permet de détecter avec précision quel équipement est défaillant.

C’est dans cette optique que les équipes NANO Corp ont conçu une nouvelle génération de sondes qui pourront être installées tant au coeur qu’en périphérie des réseaux. Contrairement aux solutions du marché, ces sondes ne s’inscrivent pas dans une logique de contournement des problématiques rencontrées mais au contraire dans une réponse d’experts à la réalité des enjeux.

Enchaînements protocolaires complexes : quels enjeux en matière de supervision ?

# Supervision des réseaux : évolution des enjeux
 
La supervision des réseaux répond à deux objectifs principaux : le contrôle de la sécurité et le suivi de la qualité de service (tant en matière d’intégrité que de performance). Une des technologies capable de superviser ces éléments est l’**analyse de protocoles**. Cette technologie, reposant sur des **sondes réseau**, existe depuis le début des années 2000, période où les débits atteignaient au maximum 1 Gbit/s.

Depuis, les débits ont augmenté de manière quasi-exponentielle :

Dans le domaine professionnel, les débits sont passés de 1 Gbit/s en 2000, à 10 Gbit/s en 2007 puis à 40 Gbit/s en 2010 ;
Pour les particuliers, leur débit internet a progressé du 56k au 512k pour passer ensuite à l’ADSL (entre 1 Mbit et 20 Mbit) et enfin à la fibre (entre 200 Mbit et 1 Gbit).
Or, la croissance de la puissance de calcul nécessaire à la supervision des réseaux n’a pas suivi le même rythme que celle des débits (croissance linéaire) aboutissant à une forme de décrochage.

## Suivre l'augmentation des débits

Comment l’analyse de protocole a tenté de suivre l’explosion des débits au cours des 20 dernières années ?
 
La multiplication des sondes pourrait être une solution évidente pour faire faire à l’explosion des débits. Mais, garantir une analyse correcte suppose que tous les paquets d’une même session soient traités par une même unité de calcul.

Afin de garantir cette unité des sessions, 3 types de solutions ont été développées :

1. La parallélisation des traitements qui nécessite de développer de nouvelles puces de parallélisation à chaque augmentation de débit et un code spécifique pour ces puces. Cela rend impossible l’évolution des capacités sans changement de hardware.
2. L’augmentation de la puissance de calcul qui nécessite de développer de nouvelles puces à chaque augmentation de débit. Cela rend impossible l’évolution des capacités sans changement de hardware.
3. La multiplication des sondes qui, limitée à certains cas précis, est sujette à des contraintes d’emplacement sur le réseau et peut engendrer des pertes d’informations.

Durant les deux dernières décenies, les travaux de R&D se sont principalement focalisés sur le développement de hardwares hyperspécialisés (_FPGA_, _ASICS_, etc.) visant à accroître les performances des sondes.

Chaque augmentation des flux ne peut être rattrapée qu’au moyen d’innovations technologiques majeures développées dans la durée qui expliquent un retard à la fois chronique et “mécanique” entre les sondes “anciennes générations” et des réseaux aux flux toujours plus denses et véloces.

Conséquence de ce décalage structurel, les différentes solutions employées par les industriels entraînent deux inconvénients majeurs. Soit les coûts explosent du fait des investissements en développement hardware pour avoir des sondes plus efficaces, soit l’empreinte au sol en terme d’infrastructure explose du fait de la multiplication du nombre de sondes.

Enfin, multiplier l’empreinte au sol ou alourdir le coût des sondes pour s’adapter aux augmentations des débits demeure une solution par défaut qui se heurte désormais à l’arrivée de la **100G**.
 
# 100G : changement de paradigme
 
Aujourd’hui, il n’est ni crédible ni viable de croire à la pérennité de l’analyse de protocole au travers de l’augmentation de la puissance de calcul grâce à un hardware hyperspécialisé. Il n’est également ni sérieux ni viable de l’envisager au travers du déport des sondes loin des cœurs de réseaux. Il faut donc repenser le hardware et le software pour répondre aux défis de demain.

Le maintien dans la course nécessite de changer d’approche : utiliser, de base, les capacités de parallélisation des équipements conventionnels.

Les fabricants des cartes réseau ont placé la parallélisation comme norme (permettant une excellente scalabilité). De ce fait, la performance des sondes ne doit plus être uniquement basée sur la performance du hardware, mais également sur celle du software.

Une démarche fondée sur une librairie indépendante du hardware offre une plus grande liberté vis-à-vis des fournisseurs et garantit un logiciel de qualité.
 
**NANO Corp, la solution d’avenir pour la supervision de vos réseaux**
 
Leur expérience des réseaux et leur certitude d’une croissance prévisible des débits, de **100 Gbit/s** aujourd’hui à **400 Gbit/s** demain, ont guidé les équipes de NANO Corp : répondre aux enjeux globaux de supervision.

C’est de la parallélisation rendue possible, tant au niveau du hardware que du software, qu’elles sont parties pour aboutir au concept NANO Corp qui offre scalabilité aussi bien verticale qu’horizontale.

Explosion des débits : quelle puissance nécessaire pour superviser les réseaux de demain ?

# Deeper, Faster, Leaner.

En amont de la levée d’amorçage d’1,6 M€ qu’elle vient de finaliser, la société NANO Corp. a franchi une autre étape importante en soumettant son moteur d’**analyse de protocole**  à l’évaluation du leader mondial de solutions de tests et de service d’assurance associés, **Spirent Communications**.

**Bruno Denjean**  Directeur Commercial **Spirent** EMEA Sud,  déclare : 

>Nous avons effectué plusieurs tests pour évaluer les performances et stresser le système en couvrant les couches réseau L2 à L7 avec une connectivité à 100 Gbit/s. L’objectif était de valider que les performances respectaient les critères stricts d’absence de paquets perdus, d’erreurs de transaction ou d’erreur de détection de protocoles, et le système d’analyse de protocoles de NANO CORP a passé tous ces tests avec brio.

Le principal objectif était de démontrer qu’un moteur d’analyse de protocole de nouvelle génération peut être développé pour les CPU (x86 et ARM). Le meilleur moyen de le prouver était de le soumettre au banc d’essai de Spirent, l’un des plus exigeants au monde. De manière délibérée, l’équipe avait choisi de le faire fonctionner sur équipement particulièrement générique : un AMD Threadripper 32 cœurs – qui n’est pas un processeur de type serveur -, équipé de seulement 64 Go de RAM sans aucune puce d’accélération pour aider le microprocesseur (donc sans _FPGA, ASIC, GPU_). 

Telles sont les conditions qui ont présidé à cette démonstration, avec la réussite évoquée par Bruno Denjean. De manière plus détaillée, voici quelques exemples de tests effectués : 

- Pour mettre en valeur ses capacités sur les couches **L2/L3**, le moteur a pu analyser avec précision et sans faute, des chaînes d’en-tête de protocole complexes avec un taux de session très élevé comme : Ethernet (4 VLAN) / MPLS / Ethernet (1 VLAN) / MPLS / MPLS / PW CW / Ethernet (pas de VLAN) / IP / UDP. 
- Il n’a jamais perdu un seul paquet à un débit soutenu de **100 Gbit/s** chargé. 
- Au niveau des couches basses du réseau, le test a déterminé que sur une connectivité soutenue de **100Gbit/s**, le système était en mesure de gérer un taux élevé de plus de _13 400 000 nouvelles sessions par seconde._ 
- Au niveau de la couche application, les tests ont démontré la capacité du moteur à identifier correctement diverses sessions d’application à la capacité maximale du testeur* : 750 000 nouvelles sessions par seconde. Avec un trafic applicatif simple, ce sont 950 000 nouvelles sessions par seconde qui ont également été facilement gérées par le système d’analyse de protocole de NANO Corp. 
- Compte tenu de résultats aussi fiables à **100 Gbit/s** sur les **couches 2 à 7**, NANO Corp. apporte la preuve que la nouvelle technologie qu’elle développe est la seule à offrir une visibilité complète sur des réseaux complexes reposant sur la virtualisation et l’orchestration automatisée.

Cette réalisation offre de nouvelles perspectives aux fournisseurs de services cloud, aux opérateurs télécoms et de datacenters dans leur volonté de récupérer la maîtrise de leurs réseaux.

**Notre actualité vous intéresse, vous souhaitez en savoir plus sur la société et ses produits, contactez-nous.**

\* Le jour du test, Spirent ne disposait pas d’équipements permettant de pousser à plus de sessions par seconde et  ne pouvait pas atteindre les capacités maximales du moteur. 

NANO Corp. a passé les tests techniques de Spirent avec brio !

En matière de supervision et de protection informatique, 4 familles de solutions conçues pour garantir la meilleure qualité de service sont historiquement présentes sur le marché : **Firewall**, Network Intrusion Detection System (**NIDS**), Network Intrusion Prevention System (**NIPS**) et **outils de monitoring**. Les 3 premières sont particulièrement orientées Sécurité tandis que la dernière permet de dépasser ce simple cadre pour s’inscrire dans des enjeux tels que le contrôle qualité des réseaux ou encore le billing.

Le panorama qui suit présente 4 familles de solutions actuelles et ouvrent la perspective des réponses pour l’avenir.

## Firewall
En bloquant le trafic indésirable entrant et sortant, les firewalls sont destinés à :

- Prévenir des attaques basiques ;
- Empêcher les usagers du réseau d’accéder à certains sites ;
- Eviter l’utilisation de protocoles dont les ports sont (généralement) fixes.

Capables de gérer de gros, voire de très gros débits (**100 Gbit/s** et plus), les firewalls sont limités à des règles de traitement simples. Ces dernières se basent très souvent sur une corrélation simple entre l’IP et le port, parfois une REGEX (ie. expression régulière) simple dans la donnée (payload) est également prise en compte. Cette simplicité explique leur manque de précision.

Les firewalls traditionnels ne font pas de classification protocolaire. Cependant, certains peuvent embarquer des NIDS en leur sein afin de proposer de l’écriture de règles plus précises (ex. au lieu de bloquer tout le flux web, on ne bloquera qu’un site en particulier). Néanmoins, les débits alors traités sont significativement plus faibles.

En résumé, les firewalls sont capables de prendre en compte de gros débits avec une faible empreinte, mais avec des fonctionnalités de protection limitées.

## Network Intrusion Detection System (NIDS)
Généralement limité à des débits de l’ordre de 10 Gbit/s, cet outil a pour vocation d’avertir les gestionnaires du réseau d’événements d’origine malveillante. Il repose sur une analyse plus approfondie du contenu des paquets que celle du firewall. Il est généralement capable de décoder et d’utiliser les informations véhiculées par les grands protocoles (HTTP par exemple).


Ses alertes se fondent sur des règles de détection plus complexes et poussées que celles d’un firewall (très majoritairement des règles SNORT). Elles peuvent être très précises lorsqu’elles s’appuient sur les champs de protocoles connus (champ Host du protocole HTTP par exemple). Elles peuvent également être beaucoup plus généralistes et ressemblent alors très fortement à celles d’un firewall. Ces spécificités apportent à l’outil une flexibilité et une précision dont ne dispose pas le firewall.

En résumé, les NIDS sont capables d’avertir les gestionnaires du réseau de manière plus précise qu’un firewall, mais sont dans l’incapacité de bloquer le flux indésirable. A la différence des firewalls, les débits supportés par les NIDS sont fortement réduits.

## Network Intrusion Prevention System (NIPS)
Cet outil n’est rien d’autre qu’une fusion entre un firewall et un NIDS. Il permet donc de bloquer le trafic de manière plus précise qu’un firewall. Malgré ces caractéristiques fonctionnelles particulièrement intéressantes, les NIPS ne résolvent pas le problème du faible débit supporté par les NIDS.

## Outils de monitoring
Les outils de monitoring permettent un suivi, en temps généralement différé, de l’état du réseau. Ces outils sont déclinés en deux grandes familles.

La première, dite spécialisée, est faite pour l’étude poussée de protocoles métiers spécifiques. Elle est limitée à de faibles débits (1-10 Gbit/s) et a pour but de fournir une vue exhaustive de certains pans du réseau.

La seconde, plus généraliste, est faite pour une étude globale du réseau par le biais de statistiques sommaires sur les sessions vues. Elle est généralement intégrée aux équipements réseau (principalement aux routeurs) et supporte des débits plus élevés (jusqu’à 100 Gbit/s). Elle peut également, en cas de besoin, faire un échantillonnage succinct des paquets passant sur le réseau (de l’ordre d’un paquet sur 10 000).

En résumé, les outils de monitoring sont capables, selon leur famille, de fournir une vue fine mais partielle du réseau ou une vue d’ensemble mais peu détaillée.

# Un moteur commun : l’analyse de protocoles
Les outils précédemment abordés ont tous besoin d’identifier et d’extraire des informations des protocoles de communication. Il existe différentes manières d’aborder cette analyse : elle peut être succincte et rapide comme celle effectuée dans les firewalls ou plus précise et plus lente comme celle qu’on trouve dans les NIDS.

L’analyse succincte se base uniquement sur les ports afin “d’identifier” les protocoles, ce qui implique de nombreuses fausses détections. L’analyse poussée, quant à elle, plonge au cœur des paquets afin de reconnaître les signatures des protocoles ce qui offre théoriquement un très bon niveau de confiance.

Par ailleurs, cette analyse profonde implique de nombreuses opérations de calcul ce qui limite le débit supporté. De plus, pour garantir des débits convenables, elle ferme délibérément les yeux devant la complexification grandissante des réseaux et se borne à un début d’analyse à partir de la couche 3 (non-gestion du tunnelling).

En résumé, il est incontestable que l’analyse de protocoles est vitale à la supervision de réseau. Il est également indéniable que la fiabilité des solutions actuelles se heurte à l’explosion des débits et de la complexification des réseaux.

# NANO Corp :  solutions de nouvelle génération pour la supervision des réseaux

Grâce à une technologie d’analyse de protocole révolutionnaire, les solutions NANO Corp viennent compléter et améliorer les outils actuels en place sur vos systèmes.

Supervision des réseaux : quels choix d’équipement s’offrent à vous ?

Les exigences en termes de cybersécurité ne cessent de croître et de se durcir que cela fasse suite à une attaque (DDOS, ransomware, etc.), un changement de standard (25/50/100 Gbit/s) ou pour s’adapter aux évolutions législatives (NIS2, Cyber Resilience act, etc.). Si, pendant un temps, les RSSI ont pu se contenter d’installer des IDS/IPS, aujourd’hui ils doivent choisir des solutions plus performantes, dans des environnements techniques et règlementaires complexes. 

Le marché des solutions s’en trouve impacté. Autrefois vecteur d’innovations majeures, il  s’est englué dans les effets de mode et des combats d’arrière-garde et a laissé  communiqués de presses et articles de commande peser plus lourd que la réalité d’avancées technologiques en perte de vitesse. 

Chaque année, l’écosystème médiatique cherche son nouveau champion et au fil du temps, le discours s’est déplacé des IDS vers les IPS, puis vers les SIEM. Récemment, c’est sur l’endpoint et autour des utilisateurs finaux (UBA – User Behavior Analytics) que se sont concentrés les efforts de développement. Ainsi, les EDR, et plus récemment les XDR  ont été mis sous le feu des projecteurs par le discours commercial. Celui qui cherche à y voir plus clair est confronté à pléthore d’articles comparatifs qui tentent de départager, au travers d’une grille d’analyse très fine, les meilleurs acteurs du marché alors que leurs principes technologiques sont identiques. 

La caractéristique commune de ces produits, tous excellents, est qu’ils ont considérablement renforcé leurs capacités de détection de menace et de protection des terminaux par le déploiement d’agents logiciels. Cependant, cette approche de la cybersécurité centrée sur les machines n’apporte qu’une protection partielle et présente encore de larges zones d’ombre et, en tout état de cause, elle ne fonctionnera que pour les menaces connues, sur un parc de machines identifiées capables de supporter un agent. 
 
 
# **Les agents, champions des solutions de cyber sécurité ?**

Si le déploiement d’agents est aussi largement répandu, c’est parce qu’il répond à un besoin croissant d’une visibilité améliorée sur tous les endpoints. Au demeurant, les solutions EDR sont bien adaptées pour détecter et protéger vos parcs informatiques contre certaines formes avancées de menaces (malware, d’APT, tentatives de phishing, etc…)  qui n'ont jamais été aussi prégnantes que depuis que le télétravail s’est généralisé.  

Mais, pour effectuer leur mission, les agents ne cessent de demander des accès privilégiés à vos ressources et vos systèmes. Certains peuvent, par exemple, envoyer le contenu de vos bases de données email en clair dans un cloud, sur lequel vous n’avez aucune visibilité, pour y appliquer des algorithmes de NLP (Natural Language Processing). D’autres vont scanner périodiquement la mémoire vive de vos machines et l’ensemble de votre File System pour être en mesure de lutter contre des menaces qui se sophistiquent de plus en plus  pour échapper aux techniques de détection des EDR.  

La nature changeante des menaces exige de mettre en œuvre des moyens accrus  pour les contrer. Or, le déploiement d’agents dans un parc informatique est un acte engageant.  Car, dans certains cas de figure, les agents peuvent devenir des portes d’entrée privilégiées à tous vos systèmes d’informations (# SolarWinds).  

Une fois qu’un EDR/XDR est  subverti ou un NIDS contourné, la capacité à être averti qu’un réseau est envahi et que des données sont peut-être en cours d’exfiltration est significativement réduite. De plus, si les EDR fonctionnent de manière correcte sur des machines équipées de systèmes d’exploitation traditionnels (Mac OS, Windows, Linux), leur efficacité est sujette à caution dans des environnements plus exotiques comme l’IoT, les équipements industriels (SCADA) ou les environnements BYOD.  


## **Pourquoi l’EDR est-il encore le grand favori des RSSI ?**

Si le déploiement d’agents continue à se multiplier de manière exponentielle, c’est à la fois parce que c’est simple : une machine-un agent et parce que l’intensité du discours commercial peut donner l’illusion que cela est suffisant pour protéger l’ensemble de l’infrastructure IT.   

A cela s’ajoute l’incapacité des acteurs connus de la sécurité du réseau à fournir des solutions performantes techniquement, abordables financièrement, et offrant une visibilité granulaire sur le réseau.  

Des solutions, type NDR (Network Detection and Response), existent mais sont incapables de suivre les évolutions des réseaux. En effet, afin de masquer leur obsolescence, elles utilisent majoritairement des raccourcis techniques, incompatibles avec une approche Zero Trust (comme le packet slicing, le packet sampling, l’exclusive_over_IP, le FPGA, etc…), tout en ayant une empreinte physique et un coût financier très élevés. 

L’approche traditionnelle de l’analyse de réseau n’a pas su faire face à plusieurs évolutions marquantes : 

- L’augmentation continue des débits (25Gbit/s, 50Gbit/s et maintenant le déploiement généralisé du 100Gbit/s) ; 
- Diversification des usages (BYOD, IoT, etc.) ; 
- Complexification des réseaux (chiffrement, virtualisation croissante, GSM over Ethernet, etc.) ; 
- Hybridisation : core-to edge, edge to cloud, edge to edge 

C’est ainsi que les EDR sont tout naturellement devenus, tant techniquement que commercialement, LA solution. A comprendre : la seule solution. Techniquement, parce qu’elle permet de contourner les difficultés en déportant la responsabilité de la sécurité en fin de parcours (End Point), sur les utilisateurs, en quelque sorte. Et commercialement, parce que la vente d’un nombre élevé d’abonnements à un prix unitaire faible, est plus aisée que de convaincre une entreprise d’investir dans des équipements plus coûteux, unitairement parlant, mais qui lui permettront d’obtenir la visibilité complète dont elle a besoin.  

Dans une approche Zero Trust de la cybersécurité, l’EDR garde, bien entendu, tout son sens, mais il ne représente qu’une brique dans une architecture plus vaste. Il ne saurait donc être l’alpha et l’oméga de la politique de sécurité d’un système d’information. Aucune solution de cybersécurité ne peut l’être ni ne devrait le revendiquer. 

![ILLUSTATION-EDR-NANO.png](/uploads/ILLUSTATION_EDR_NANO_d3dcd0272b.png)
_L'EDR est un outil nécessaire, mais il ne constitue pas toute la panoplie... ..._ 

## **Un NDR oui ! Mais en mode Zero Trust !**
Comme évoqué plus haut, des solutions d’analyse et de sécurité des réseaux tentent déjà de résoudre certaines problématiques cyber qui pourraient s’inscrire dans une démarche Zero Trust, laquelle pose comme cadre (framework) de ne faire aucune confiance a priori : tout est contrôlé, de l’infrastructure à l’utilisation, en permanence et pas seulement les droits d’accès. 

Or, les solutions de sécurisation réseau sont généralement toutes pénalisées par l’emploi de raccourcis matériels et logiciels qui leur imposent de faire une confiance totale à des éléments qu’elles ne maitrisent pas (id est se contenter d’une visibilité sur certains protocoles over IP, par exemple) ou d’user d’«astuces» statistiques pour compenser leur inefficience (sampling, slicing, etc.). 

Le mirage des statistiques constitue, à cet égard, un exemple frappant. Certaines solutions commercialisées appliquent des procédés de Machine Learning (M/L) pour faire de la détection. Le problème est qu’il est hasardeux de baser son M/L sur des valeurs statistiques elles-mêmes issues d’échantillonnages non maîtrisés. Dans tous les cas de figure, il n’est pas possible d’être conforme à un framework s’inspirant du  Zero Trust (lui-même de plus en plus dévoyé pour des raisons marketing). 

 L’emploi du Machine Learning pour renforcer des capacités de détection et d’alerting avancées et  prévenir  l’utilisateur d’anomalies complexes liées au détournement d’applications et de processus, est, conceptuellement, satisfaisant, à la seule condition d’en connaître les limites. Reposant sur des données parcellaires, il ne peut prétendre à l’exhaustivité et à une observabilité complète des réseaux. Il en va de même si l’on se cantonne à de l’analyse de réseau au-dessus des flux IP voire même uniquement over_TCP ! 

Si l’observabilité n’est pas complète, cela revient à analyser un iceberg en se contentant de la partie  émergée : la partie immergée reste dans l’ombre.  En renonçant à cette capacité, on laisse perdurer les zones d’ombre des réseaux, qui ne cessent de se multiplier avec la généralisation de la virtualisation, le Shadow IT, le BYOD, etc... 

Ajoutons que même avec des NDR très performants (comme Extrahop ou Vectra), l’obligation d’utiliser des matériels spécifiques les rend, par définition, très peu scalables et les enferme dans un cadre d’usage très restrictif.  

Malheureusement, la version logicielle de leur suite applicative, de par sa faible performance (ratio ressources requises/flux traités) provoque une explosion des coûts de hosting. Ces performances très limitées les éloignent toujours plus du Zero Trust dont elles se revendiquent.  

## **Que doit faire un CISO pour augmenter sa protection, réduire et contrôler sa surface d’attaque ?  **
Évidemment ajouter un NDR dans sa suite pour compléter son EDR. Mais un NDR capable de faire du Zero Trust Traffic Analysis (Z2TA), c’est-à-dire une analyse complète de chaque paquet sur l’ensemble des couches et capable d’en extraire toutes les métadonnées indispensables (ce qui exclut les technologies à base d’échantillonnage).  

Le Z2TA oblige à repartir d’une page blanche pour répondre à l’ensemble des problématiques précédemment exposées et permet d’offrir aux RSSI la visibilité sans concession, c’est-à-dire sans biais conceptuel, de leurs réseaux. Le Z2TA est la solution d’avenir qui permet de contrer un ensemble de menaces que les EDR ne sont pas en mesure de voir, et dont ils sont parfois le propre vecteur. 

**Le  Zero Trust Traffic Analysis est un outil indispensable de la panoplie du CISO pour répondre aux plus hautes exigences en matière de cybersécurité.**

EDR : Au delà du Buzz

# NANO Corp. à VivaTech !

Grâce à [Intel Ignite](https://www.linkedin.com/company/intel-ignite/) et aux incroyables opportunités qu'ils nous offrent régulièrement, NANO Corp. sera présent à Viva Tech pour son édition 2022 ! 

Nous aurons un e-booth, venez y jeter un coup d'œil et nous vous montrerons ce que veut réellement dire “maitriser ses réseaux”. Et on sera là pour la demo day, jeudi ! 

Vous pouvez également y assister via ce [lien](https://app.vivatechnology.com/session/3c5bfa00-08e7-ec11-b656-a04a5e7d2a9d ), surtout si vous souhaitez voir notre CEO parler en direct ! 

Edit : si vous désirez voir notre CEO pitcher, c'est juste en dessous ;-)

NANO Corp. à VivaTech ! 

# Clickhouse  meetup


S’il n’y avait qu'une seule raison pour laquelle nous aimons autant [ClickHouse](https://www.linkedin.com/company/clickhouseinc/), je dirais que c'est parce que nous avons l'impression de faire des choses qui étaient impossible avant !  

C’est aussi simple que cela.  

Vous voulez savoir comment ? Alors venez écouter deux de nos fondateurs vous l'expliquer lors de la conférence Clickhouse Meet-up at Content Square 

Et c'est ici que cela se passe : [https://www.meetup.com/clickhouse-france-user-group/events/286304312/](https://www.meetup.com/clickhouse-france-user-group/events/286304312/)

![Clickhouse meetpup.jpeg](/uploads/Clickhouse_meetpup_0b41234ff8.jpeg)

Rendez-vous Clickhouse !

# Le FIC 2022 est terminée !

Job done! 
 
Merci à toute l'équipe NANO Corp, au jury, merci au [FIC (International Cybersecurity Forum)](https://www.linkedin.com/company/forum-international-de-la-cybers%C3%A9curit%C3%A9/), merci à [Atos](https://www.linkedin.com/company/atos/) et à l'[European Cyber Security Organisation (ECSO) ](https://www.linkedin.com/company/ecso-cyber-security/)

Vous pouvez être certain que ce prix est le premier d'une longue série de récompenses ! 

https://www.forum-fic.com/

Merci également à ceux qui sont venus nous rendre visite au cocktail et fêter avec nous l'obtention du prix Cybersecurity for Industry !

![Prix du CFI #2.jpeg](/uploads/Prix_du_CFI_2_08e8468373.jpeg)

Forum International de la Cybersécurité édition 2022

Avons-nous dit à quel point nous sommes fiers de nos équipe ?Probablement déjà quelques fois.

Eh bien, voici une raison de plus :
 
Parmi des centaines de candidats, seulement 13 sélectionnés, 1 seul français -> NANO Corp
 
Avec Google Cloud, nous concentrerons notre travail sur les opérations cloud et l'apprentissage automatique pour fournir notre solution d'observabilité du réseau à [Google Cloud](https://www.linkedin.com/company/google-cloud/) et à ses clients.


Si vous voulez savoir pourquoi nous avons été selectionnés, le mieux est d'aller voir ce qu'en dit Google : [https://cloud.google.com/blog/topics/google-cloud-europe/first-google-for-startups-accelerator-cloud-in-europe](https://cloud.google.com/blog/topics/google-cloud-europe/first-google-for-startups-accelerator-cloud-in-europe ) !



1er Google  Cloud Startups Accelerator en Europe

# Venez nous voir au FIC !

Vous voulez parler à des experts du réseau ?
 
Je sais où les trouver, au FIC (International Cybersecurity Forum) sur le stand E1-16 de NANO Corp !

En plus, il y aura un cocktail sur le stand de NANO Corp à 17:30 le 8 juin. Stand E1-16 sur le pavillon CFI. Venez nous y retrouver pour fêtez avec nous l'obtention du prix Cybersecurity for Industry!

![FIC Forum International Cybersécurité.jpeg](/uploads/FIC_Forum_International_Cybersecurite_e13a104c86.jpeg)


Nous serons au FIC !

# Remise du prix du CFI à NANO Corp. !

Est-ce un sourire ? Bien sûr que oui, c'en est un ! NANO Corp a remporté le prix de la cybersécurité pour l'industrie du [FIC (International Cybersecurity Forum)](https://www.linkedin.com/company/forum-international-de-la-cybers%C3%A9curit%C3%A9/) !  
 
En tant que tout premier lauréat de ce prix, nous sommes mis au défi de contribuer à le rendre aussi prestigieux que possible ! 


Vous voulez en savoir plus ? Venez nous rencontrer sur le stand E1-16, à Lille, du 7 au 9 juin.

![Deux fondateurs de NANO Corp. heureux après avoir reçu le prix du CFI](/uploads/Prix_du_CFI_8ead9a09c4.jpeg)

Prix du CFI (Cybersecurity For Industry) 2022 !

# NANO Corp. rejoint le programme de croissance de startups Intel Ignite !

Nous avions mentionné il y a quelques semaines une importante annonce à venir.    
L’information est désormais officielle : NANO Corp est sélectionnée pour participer au programme de croissance de startups de [Intel Ignite](https://www.linkedin.com/company/intel-ignite/) Europe !    
 
NANO Corp est très fière d’avoir été choisie, à la suite d’une sélection rigoureuse, dans l'un des programmes d'accélération les plus stimulants et compétitifs au monde.  
 
Intel Ignite est le programme d'[Intel Corporation](https://www.linkedin.com/company/intel-corporation/) dédiés aux #startups dont les technologies à la fois audacieuses et innovantes vont bouleverser leurs secteurs.  
 
Grâce au mentorat, à la mise à disposition de ses moyens techniques, Intel démultiplie les capacités de ces startups et leur permet d'atteindre de nouveaux sommets !

Booster on !

https://intelignite.com/program/

![Intel Ignite.jpeg](/uploads/Intel_Ignite_1a930d2452.jpeg)

Intel Ignite et NANO !

# NANO Corp. rejoint l’ACN

Après avoir pris le temps de regarder les différents cadres d'expression, nous avons choisi de rejoindre l'[ACN - Alliance pour la Confiance Numérique](https://www.linkedin.com/company/alliance-confiance-numerique/) pour porter nos convictions en matière de cybersécurité.

Nous sommes très impatient de participer aux premières réunions d'information et de rencontrer les autres membres !

![Alliance pour la confiance numérique.jpeg](/uploads/Alliance_pour_la_confiance_numerique_d908657403.jpeg)

Nous rejoignons l'ACN

Que dire de plus, si ce n'est que nous sommes fiers de pouvoir rejoindre l'ensemble des membres du Pôle d'Excellence CYBER!

![Pôle d'excellence Cyber.jpeg](/uploads/Pole_d_excellence_Cyber_1395f2d41b.jpeg)

Nous rejoignons le Pôle d'Excellence Cyber !

# Prix du FIC ?

Hier je vous annonce la sélection de NANO comme startup DeepTech, aujourd'hui nous sommes fiers d'être pré-sélectionnés pour le prix du FIC. Encore plusieurs annonces à venir ces prochains jours ..

Pour l'occasion, Fanch FRANCIS, notre CEO, a été interviewé par le comité en amont de la présentation de nos projet pour l'industrie !



Nous serons bien entendu au FIC2022 !

![FIC Forum International Cybersécurité.jpeg](/uploads/FIC_Forum_International_Cybersecurite_e13a104c86.jpeg)

Sélection pour le prix du FIC !

# Reconnaissance de la Deep Tech 

NANO Corp. a été reconnue comme une entreprise Deep Tech par BPI .   

Au-delà de l’aide financière, cette reconnaissance par un panel d’experts réseaux, vient conforter la décision prise par les fondateurs de Nano Corp de toujours être à la pointe de la recherche dans le domaine de la sécurité des réseaux.   

![Deep Tech.png](/uploads/Deep_Tech_87c1a1bb13.png)

La BPI nous accorde le label Deep Tech

# NANO Corp. à la European Cyber Week

Nous sommes honorés de faire partie des partenaires de la 6e édition de la [European Cyber Week](https://www.linkedin.com/in/ACoAACe4a5MBX9AH_jnPkIJf2UzpW9QTYGZzw6U).  
 
Nous viendrons présenter le fuit de nos développements : des outils de capture et de supervision des réseaux à destination des opérateurs de télécommunications qui  assure une visibilité complète sur tous les trafics réseaux du cœur à l’edge, pour une maîtrise totale des flux. 
 
Si vous souhaitez nous rencontrer, cela sera sur notre stand au Couvent des Jacobins à Rennes, du 16 au 18 novembre 2021 !

![ECW European Cyber Week.jpeg](/uploads/ECW_European_Cyber_Week_5f4f859b9b.jpeg)

European Cyber Week 2021

# Certaines de nos réserves concernant le  DPDK 

 
Notre premier set de drivers RUST, pour les **cartes Intel 1G, 10G et 40G** est terminé (nous vous en écrirons un peu plus sur le sujet, mais nos benchs sont vraiment brillants !). Nous les faisons tourner en userspace, comme notre sonde !

Une question qui nous a assez souvent été posée lors du dernier FIC (2022) a été :

> “Pourquoi ne pas avoir utiliser le DPDK ?”

Comprendre : 
>” Mis à part un côté masochiste, y’a-t-il une raison valable ?”

Quand **Intel**, inventeur du DPDK en 2010, nous a choisi pour être une des 10 startup à accélérer dans leur programme **Intel Ignite** en 2022, la même question nous a été mainte fois posée par nos interlocuteurs interloqués.  

## Notre relation avec le DPDK: It's complicated

Il est temps maintenant d’exprimer les réserves que nous avons sur le DPDK dans notre contexte et les raisons qui nous ont motivé à choisir une autre voie. 

La réponse à cette question pourrait se résumer à “_on développe déjà tout en Rust, nous sommes déjà tellement habitués à souffrir que décider de développer nos propres drivers de carte réseau n’a été qu'une décision comme une autre_”. Du coup, oui, il y a définitivement un attrait pour la douleur.  

Plus sérieusement, la réalité est la suivante : lorsque nous avons développé notre sonde réseau, avec pour objectif d’atteindre le 100Gbit/s (https://nanocorp.fr/en/nano-corp-passed-spirent-s-technical-tests-with-flying-colors/), nous avons constaté que l’emploi du DPDK posait de nombreux problèmes. Tout particulièrement lorsque notre objectif était d’analyser les réseaux à des fin de cybersécurité. 

Le DPDK est une technologie open source plutôt révolutionnaire. Elle a été initialement développée, puis proposée, par Intel pour les environnements Linux. Son objectif étant de fournir des librairies de Data Plane et des pilotes gérant les cartes réseaux. 

Pour ceux qui ne sont pas familier avec le DPDK, cette technologie est apparue en 2010 et venait dépoussiérer la stack réseau Linux existante, qui était vieillissante et vraiment pas très performante. 

## le DPDK, comment cela fonctionne ?

Lors de son démarrage, un logiciel réseau fait appel au noyau pour configurer une méthode d’acquisition des paquets. Plusieurs technologies existent, dont les plus populaires sont certainement **AF_Packet** (natif dans Linux),**AF_XDP**, **DPDK**, ou encore **Netmap**. 

Avec le DPDK, le noyau sera par défaut entièrement contourné et un pilote (driver) différent, en charge de la gestion de la carte réseau, sera utilisé. Cela a permis au DPDK de rapidement s’imposer en remplacement de la pile réseau traditionnelle du **Kernel/Linux**. 

Le DPDK utilise plusieurs stratégies afin d'obtenir des performances maximums. L'allocation par le DPDK de cœurs CPU dédiés garantit de meilleures performances des “applications réseau” (en termes de traitement de millions de paquets par secondes). Les “grandes pages mémoires” (**hugepages**), quant à elles, assurent un accès plus uniforme dans le temps aux ressources mémoires (**memory pool**), ce qui réduit le nombre de “**TLB miss**” (translation **lookaside buffer**). Il existe bien sûr encore plein d'autres techniques d'optimisations (on peut notamment citer la récupération des paquets par batchs, ou encore le contournement du noyau qui induit aussi une réduction des opérations de copie/récupération au niveau de la mémoire tampon.) 

De manière générale, la charge réduite sur le processeur permet souvent d’obtenir des performances intéressantes. Et comme le rappelle Intel : “_Le DPDK supprime certains des goulots d'étranglement impliqués dans le traitement des paquets. En déplaçant les tampons mémoire dans l'espace utilisateur et en effectuant des interrogations plutôt qu'un traitement basé sur les interruptions, le DPDK est en mesure d'améliorer les performances avec de petites tailles de paquets._” (R-IOV for NFV Solutions - Practical Considerations and Thoughts Technical Brief - Authors: Patrick Kutch Cloud Solutions Architect Solutions Enabling Team, Intel Brian Johnson Solutions Architect Networking Division, Intel). 

Aujourd’hui, en environnement hypervisé, grâce à l’utilisation du DPDK, d’**Open vSwitch** (OVS) et de la gestion des Fonctions Virtuelles, il devient possible de bénéficier d’un nombre conséquent d’optimisations intéressantes, surtout dans le cas de la transmission de paquets inter-machines virtuelles (comprendre, les **VM** sur une seule machine physique). 

## Du coup, pourquoi pas le DPDK ? 

Lors de nos expériences, nous avons constaté que le DPDK connaissait aussi certaines limitations qui viennent lourdement impacter les performances des solutions reposant sur l’analyse protocolaire. Parmi ces limitations, nous en avons dégagé 4 principales qui nous ont poussé à ne pas faire reposer notre solution sur cette technologie : 

1 La difficulté de compilation/maintenance du DPDK, 
2 La difficulté de configuration/déploiement du DPDK, 
3 L'absence (à date) de compatibilité avec le Rust, 
4 Son framework qui impose d’avoir ses propres threads. 

Ce dernier point implique qu’on ne peut pas l'utiliser uniquement comme un backend de lecture de paquet. Une solution utilisant le DPDK ne peut alors utiliser que le DPDK or nous souhaitons avoir une large compatibilité. 

Ce ne sont pas les seules contraintes ou limitations que nous avons rencontré, bien qu’elles aient été déterminantes dans notre abandon de cette technologie. Parmi les autres points qui nous ont contrarié, nous pourrions néanmoins mentionner à titre d’exemple : 

- Le DPDK est un cadriciel (Framework) compliqué à maintenir du fait de ses systèmes hérités (Legacy), ce qui le rend d'autant plus difficile à adapter pour des environnements réseaux complexes,

- Lors de mises à jour du DPDK, on constate des pertes de comptabilité avec les matériels autrefois compatibles, 

- L’implémentation au niveau des cartes réseaux est également complexe à mettre en œuvre, 

- Le DPDK gère ses propres threads, qui sont externalisé du noyau. Il a donc son propre scheduler (ordonnanceur). Et comme il est initialisé au démarrage, il n’est pas possible d’y apporter des modifications sauf par un redémarrage de tout le système. Ce qui a un impact sur la scalabilité dynamique de toute solution construite sur le DPDK, 

- Au cours de travaux de recherche et développement, nous ne sommes jamais parvenus à tenir un débit de 100Gbit/s (148.800.000 de paquets par seconde) avec des paquets de petites tailles (64 octets) avec le DPDK. Et cela, sur plusieurs cartes réseaux différentes. Ce niveau de performance est pourtant celui annoncé par le framework DPDK, 

- Les drivers de cartes réseau implémentés dans le DPDK ont leurs propres threads (de Cœur CPU), ce qui pousse parfois, selon les use case, à des systèmes de call-back (fonction de rappel) qui peuvent provoquer un overhead sur les ressources processeurs qui est important lors de l’enregistrement des paquets en PCAP. 

- A l’usage, nous avons noté un plateau lorsque certaines solutions à base de DPDK doivent utiliser plus de 30 cœurs. 

Ces points peuvent néanmoins évoluer, le DPDK étant régulièrement mis à jour, il se peut que parmi les points évoqués, certains soient résolus lorsque vous lirez cette article.

**L’objectif de NANO Corp est l’observabilité unifiée**, c’est à dire la capacité de superviser les réseaux physiques comme cloud avec la même plateforme. Le développement de nos sondes cloud (spoiler alert : grosse annonce à venir) nous imposait de prévoir les impacts potentiels du DPDK dans ces environnements.  

Bien que nous n’en ayons pas fait l’expérience du fait d’autres choix de développement, en environnement virtualisé il a également été noté que le DPDK peut avoir des difficultés à rendre scalable la manipulation des paquets. Comme il est dit ici : « _OVS-DPDK fonctionne de manière très similaire dans nos environnements de test, évoluant de manière linéaire pour les VNF initiaux, mais atteignant ensuite un plateau de débit système à mesure que d'autres VNF sont ajoutés. Nous montrons que ce plateau est fonction des ressources CPU allouées aux fonctions de commutation virtuelle de OVS-DPDK_ ». (Pitaev et al., 2018 Characterizing the Performance of Concurrent Virtualized Network Functions with OVS-DPDK, FD(.)IO VPP and SR-IOV). 
Nous craignions donc que plus l’hyperviseur aurait de machines virtuelles à gérer, plus la solution d’analyse de protocoles serait rapidement saturée. Une hypothèse qui s’est vérifié lors de nos recherches. Une saturation qu’il n’était pas pertinent de chercher à contourner tant que cette technologie n’aurait pas évolué.  

C’est à la lumière de toutes ces difficultés que nous avons décidé de contourner le DPDK et de redévelopper une solution fonctionnant entièrement en userspace, drivers de NIC compris. Article à venir sur le sujet. 

Si vous avez rencontré des problèmes similaires ou si vous ne partagez pas cette analyse, nos chercheurs et développeurs maison se feront un plaisir d’échanger avec vous sur le sujet. 

N’hésitez pas à prendre contact ! 



Certaines de nos limitations avec DPDK

Arrivés aux limites matérielles de leur solution logicielle, de nombreux fournisseurs de sondes réseaux, se sont tournés vers le FPGA au cours de la dernière décennie. Cette approche devait alors permettre de contourner leur incapacité à suivre la complexification croissante des réseaux. 

Le FPGA (pour Field Programmable Gate Array) est une technologie dont les performances et les qualités sont reconnues. Notre expérience a cependant démontré que dans un cadre d’analyse des paquets réseau à des fins de cybersécurité, cette technologie ne répond pas forcément aux exigences d’un cadre Zero Trust, à savoir une analyse intégrale d’absolument chaque paquet sur chaque couche, qui plus est quand la sécurité doit prendre en compte un déport progressif vers le Cloud.  

Plus particulièrement, les limites du FPGA, dans le cadre de l’analyse des réseaux, méritent d’être mises dans le contexte de nouveaux défis comme la généralisation croissante de la virtualisation ou le tunneling, qui imposent aux solutions de maitriser les couches basses. A cette problématique, s’ajoute à la fois celle des [empilements protocolaires complexes](https://nanocorp.fr/enchainements-protocolaires-complexes-quels-enjeux-en-matiere-de-supervision/) ainsi que celle de l’évolution constante des réseaux, car de nouveaux protocoles apparaissent régulièrement alors qu’il en existe déjà une multitude ! 

Nos arguments sur l’imperfection d’un emploi exclusif du FPGA pour adresser les besoins de monitoring et de protection des réseaux sont double, à la fois technique et commercial. 

 
## Arguments Techniques

Pour rappel, le FPGA est un circuit composé d’Arrays qui peuvent être reprogrammées après fabrication (ce qui n’est pas le cas du CPU). Il est donc possible de configurer ces Arrays et d’en définir, pour un usage donné, les interconnexions. Alors qu’un CPU exécutera plusieurs millions d’instructions en fonction de ce qui lui est demandé, un FPGA pourra arriver au même résultat en seulement quelques cycles. 

Idéal dans le secteur de l’automobile, de la finance ou dans l’environnement du réseau (LUA chip), il devient cependant plus compliqué d'utiliser un FPGA lorsque les problèmes que l’on souhaite adresser sont à chercher dans une intrication complexe de traitements conditionnels de la donnée.  

Notre expérience tend à montrer que le FPGA n'est plus au rendez-vous des performances attendues lorsqu'il est nécessaire de développer des processus de traitement construits sur des suites d’imbrications conditionnelles parallélisées (algorithmes à base d'arbre de décision complexe et récursif, par exemple). 

Le FPGA est très performant lorsqu’il faut tester un ensemble de conditions simultanément. Ce qui en fait un excellent outil dans le traitement du signal réseau, par exemple (Couche 1 du modèle OSI) ou quand il est question de paralléliser les traitements. 

En revanche, quand le nombre et la diversité des protocoles à classifier est trop complexe (protocoles multiplexés, enchainements protocolaires complexes, etc.), les solutions à base de FPGA auront alors tendance à ne pas classifier les protocoles qui ne s'annoncent pas. Ce qui a pour conséquence d’augmenter l'imprécision et de provoquer une perte de visibilité. 

Parmi les raisons qui nous font penser que le FPGA a de nombreuses limitations techniques dans le domaine de la visibilité des réseaux, voici pour nous, ceux que nous avons jugé les plus marquant ou limitant : 

- Le FPGA ne s’est pas montré performant sur la parallélisation séquentielle de boucle conditionnelle dynamique avec comme conséquence de se concentrer exclusivement sur la gestion de certaines couches basses. Celles qui annoncent correctement les protocoles qui les suivent (et plus les couches protocolaires s'empilent de manière dynamiques et imprécises, moins le FPGA devient pertinent). Au-delà de la couche 4, il devient alors rarement possible au FPGA de classifier correctement des protocoles réseau. De la même manière, les environnements à base d'empilement de protocoles virtualisés, quand ils sont traités, ne le sont que pour un nombre d’itérations données. Rendant le déploiement de telles solutions en cœur de réseau, de type data center, moins pertinent. 

- Limité sur les couches hautes et sur les protocoles ne s'annonçant pas, il devient difficile de créer certains filtres complexes avec du FPGA. De nombreuses solutions se contentent de ne traiter que quelques protocoles de couches basses et uniquement sous certaines conditions (MPLS si c'est le protocole IP qui le suit, ou VxLAN, mais sur les ports uniquement). 

- Les réseaux sont devenus très dynamiques, et il n’est pas rare de voir certaines aberrations en termes d’empilement de réseaux (virtuels ou physiques), surtout en environnements hybrides. Le FPGA étant quant à lui quasiment stateless, il lui est alors compliqué de classifier correctement des protocoles lorsque qu’il est nécessaire d’en détenir plusieurs paquets, surtout lorsque le débit est élevé et que la mémoire de la carte est limitée. 

- Le FPGA aura les plus grandes difficultés à dépiler une succession d’empilement de protocoles de tunneling et de protocoles multiplexés.  

- Les FPGA ne sont pas agiles. Les protocoles réseaux ne sont pas immutables. Ils changent constamment et il n’est parfois pas rare qu’ils évoluent ou que de nouveaux protocoles apparaissent. Le Time-To-Update avec du FPGA est plus élevé et il aura du mal à gérer les erreurs inconnues. 

- Une solution “compilée” pour un FPGA ne fonctionnera pas en dehors de la même carte FPGA. 

- A une époque où une part croissante des applications migrent vers le cloud, il est toujours impossible de virtualiser des FPGA, ce qui rend définitivement le FPGA incompatible avec l’un des avantages majeurs du cloud à savoir la scalabilité dans l’architecture de ses solutions. 

Si le FGPA répond à des problématiques de visibilité bien délimitées, son approche n’est pas **Zero Trust**, puisqu’elle accepte de sacrifier l’observabilité au profit d’un traitement de volumes de données plus élevés. 

## Argument Commerciaux 

Notre solution, le **Zero Trust Trafic Analysis**, répond aux problèmes techniques évoqués ci-dessus. Elle permet en outre de construire un argumentaire commercial solide autour des réalités techniques suivantes : 
- Le FPGA est dit “Vendor Locked” et “Machine locked” (Il devient impossible de transférer sa solution d’analyse de protocoles sur une autre machine à distance si celle-ci n'a pas la même carte FPGA ni même des caractéristiques hardware équivalentes)  

- Le FPGA interdit toute forme de scalabilité hormis par l’achat de matériel supplémentaire (vous souhaitez augmenter le débit ou rajouter des interfaces, il faut repasser à la caisse). 

- La pénurie de semi-conducteur impacte plus encore les puces spécialisées comme le FPGA 

- Une solution FPGA engendre un TCO (Total Cost Ownership) plus élevé : un serveur puissant, coûteux et plusieurs cartes FPGA sont indispensables pour les environnements à haute densité (Data Centers) où l’overhead est à bannir 

- L'orchestration de solutions construites pour des architectures comme les CSP/Data Center est impossible. 

A la lecture de ces arguments, nous espérons vous avoir convaincu ou tout du moins avoir ouvert le débat.  Ces propos peuvent sembler incendiaires. Ils ne le sont pas. Le FPGA reste un outil formidable. Mais nous pensons sincèrement qu'il est devenu trop contraignant de l'utiliser pour de l'analyse de réseau.  

 Nous estimons que le FPGA se prête mal à l’analyse **Zero Trust** de protocoles car son utilisation est restrictive et sa capacité de déploiement limitée aux infrastructures propriétaire. Or le contexte des réseaux est amené à se complexifier continuellement (nouveaux usages) et les infrastructures à se mutualiser (shift vers le cloud). Dans ce contexte, la seule approche qui fait sens sera celle devant privilégier une très haute capacité d’adaptation et une plus grande intégration. L’approche choisie par NANO Corp. 

Le FPGA pour une analyse Zero Trust des paquets réseaux, la fausse bonne idée. 

# Pourquoi enregistrer ses flux réseaux ? 

  
![Sans titre.png](/uploads/Sans_titre_df8fe95079.png)

Et surtout, pourquoi le faire avec notre solution, **n.Rewind**  

  
## PCAP or it didn’t happen 
**L’acte reflexe du cyber combattant.** 


Appelé PCAP (pour Packet CAPture, format d’enregistrement de données réseau le plus connu), l’enregistrement du trafic réseau est une pratique courante autant pour les admins réseau que pour les spécialistes de la cybersécurité.   

Un fichier PCAP est un enregistrement dans un format binaire (avec ~20 à 30% d’overhead par rapport au flux original). Il offre une visibilité totale des évènements passés. Il permet de faire des instantanés complets du réseau pour les analyser.  

C’est le replay de votre réseau, revivez vos épisodes préférés tel que _l’épisode DDOS_ ou celui sur l_e ransomware_ ou encore_ le process DHCP_    
Sans une trace PCAP, opportunément faite, il n’est pas possible d’effectuer une analyse forensic efficace. Se pose là le **challenge n°1 : comment faire la capture à temps ?**  

## Un PCAP pour quoi faire ? 
**Tout ou presque.**

Un PCAP sert de base pour analyser et aider à contrôler l’état de santé du réseau (par ex. ICMP flood ou lag au niveau de sessions TCP), mais aussi détecter les anomalies et activités malicieuses. Le PCAP permet de remonter à l’origine du problème que l’on souhaite identifier sur le réseau.  

Superviser la source ou la destination du trafic, identifier les données des “applications” et les appareils, détecter l’origine et les causes des dysfonctionnements (pouvant aussi être des indicateurs de compromission, ou IoC), etc...   

Dans l’ensemble, on peut dégager 4 grandes catégories d'usage de la capture de paquets :  
- **Identifier** les points de congestion : grâce de la capture, il est possible d’observer le trajet de tous les paquets, ce qui peut aider à identifier des points congestion
- **Dépanner** (ou troubleshooting) : la dimension granulaire d’un PCAP (c’est à dire le fait d’avoir tous les paquets) est la solution idéale (bien que très chronophage) pour identifier précisément un problème et sa source,  
- **Explorer** : composant essentiel du forensic,  le PCAP est souvent indispensable pour identifier ou confirmer la présence de malware, la détection de comportements malveillants et les failles de sécurité  
- **Conserver une preuve** : le PCAP permet de partager un ensemble cohérent, complet, diffusable d’un évènement réseau.  

Pour être utile un PCAP doit à la fois permettre de détenir l’intégralité de l’évènement, mais aussi de rester exploitable (temps d’exploration/taille de l’enregistrement) plus il est gros plus il est complet plus il faut du temps pour isoler les éléments d’intérêt. Arrive donc le **challenge n°2 : comment faire une capture ciblée ?**  


## Un PCAP c’est facile ? 
**Enfantin.** 

Sauf si : vous êtes dans le cloud ou dans des environnements hybrides ou à haut débit, sous contrainte d’un SLA exigeant, ou sous le feu d’une attaque.  

Un analyste de niveau 2 d’un SOC contribue à la remédiation des cyberattaques en collectant des données sur les hôtes et le réseau en vue d'une analyse plus approfondie et en déclenchant les mesures de sécurité appropriées conformément au plan de réponse aux incidents. Les principales difficultés auxquelles il sera confronté sont :   
- Informations inexistantes ou incomplètes ou surabondantes sur ce qui s'est passé avant et après le cyber incident 
- Même si des données forensic sont disponibles, elles peuvent être très volumineuses, coûteuses à stocker et extrêmement longues à explorer et à analyser manuellement 
- En plein incident il peut être compliqué d’effectuer une capture utile et de passer d'un outil à l'autre pour analyser les paquets 

Vous l’aurez compris, **challenge n°3 : comment faire une capture dans le feu de l’action ?**  

  
## La taille, ça compte ? 
**Oh que oui ! Mais l'usage aussi !**  

  Si vous souhaitez procéder à une capture en cœur de réseau, la taille des PCAP dépassera souvent les capacités des outils utilisés pour l’exploiter. De plus il sera difficile de collecter des conversations (ou sessions) complètes parce que votre outil de capture n’est pas suffisamment performant. C'est d’ailleurs pourquoi nous vous recommandons de prendre en considération le taux de stream-to-disk, une métrique à laquelle il est tout particulièrement important de faire attention dans les environnements dont les débits dépassent le 10Gbit/s. Il n’est pas rare, lorsque les débits sont élevés, que les outils de capture annoncent des performances qu’ils ne sont capables de tenir que sur une poignée de secondes. Une limitation que certains n’ont pas peur de marketer en fonctionnalité, appelée “microburst”.  

A l’inverse, si la capture est réalisée à la périphérie du réseau, la visibilité en sera forcément limitée. Et nous pourrions rater la détection d'un DDoS ou d'un malware.  

La confluence de ses contraintes a fait naître une citation courante que nous entendons souvent chez certains de nos prospects : « Il m’arrive de passer deux à trois jours pour extraire ce que je cherche ». Ce qui souligne vraiment bien la nécessité de « retrouver ses petits », qui est l’expression employée par nos experts maison.  

  Et ce problème récurrent ne saura se résorber à mesure que les débits des réseaux d’entreprise augmentent. Wireshark est déjà dans l’incapacité d’enregistrer des flux réseaux à 1Gbit/s sans perte de paquet. Mais déjà, certains FAI proposent des offres clients à 2,5 Gbit/s et d’autres à 8Gbit/s (même si leur offre est marketée à 10Gbit/s). Les Data Centers passent du 40Gbit/s à du 100Gbit/s et il est prévu de généraliser le 400Gbit/s à la fin de cette décennie. Procéder à des captures de paquet dans ces environnements n’est plus possible si on se contente des outils et matériels actuels.   

  Du coup, **challenge n°4 : comment retrouver ses petits dans les gros PCAP?** 
  

## Introducing n.Rewind 
  
![Capture d’écran 2022-10-06 à 17.30.11.png](/uploads/Capture_d_ecran_2022_10_06_a_17_30_11_bb33e801f9.png)

**La capture intelligente de paquets** 

Comme vu ci-dessus, le cyber combattant fait face à 4 challenges compliquant sa capacité à bénéficier d’une trace utile : 
- challenge n°1 : comment faire la capture à temps. 
- challenge n°2 : comment faire une capture ciblée.  
- challenge n°3 : comment faire une capture dans le feu de l’action.  
- challenge n°4 : comment retrouver ses petits dans les gros PCAP.  

Ces challenges sont renforcés par l’évolution constante des réseaux (core to edge, edge to cloud, edge to edge), par l’hybridisation et l’accélération des débits. RIP tcpdump.  

n.Rewind est l’outil de capture paramétrable que nous avons conçu dans le but de répondre à l'ensemble des challenges précédemment évoqués. Il permet une capture complète ou filtrante, automatisée et inclus un buffer pour être certain de ne pas rater le début du show.  

Pour ce faire, nous sommes partis d’une feuille blanche et nous avons réalisé que seul notre technologie de sonde réseau était en mesure d’apporter une réponse nouvelle à cet ensemble récurrent de problématiques. L'application de notre technologie de sonde sur la capture nous a permis de :  
- **Bénéficier d’un buffer** (dont la taille dépendra de la RAM que vous lui allouerez), ce qui permet de détenir un enregistrement détenant les “moments réseau” qui précèdent son déclenchement, utile pour des analystes en cyber sécurité qui cherche à comprendre le chemin d’attaque ou les signaux faibles propres à une activité. 

- **Effectuer des déclenchements automatiques** sur filtres ou sur API.  

- **Filtrer en amont**, c’est à dire sur du cœur de réseau à 100Gbit/s. Avec un jeu de filtres qui est bien plus complet et utile que le 5-tuple et qui prend en compte certains empilement protocolaires complexe comme le tunneling, les multiples VLAN, le MPLS, etc... Une manière très efficace d’obtenir un PCAP léger quand on sait exactement ce que l’on cherche dans des gros tuyaux. Au même titre que notre expérience précédente, passer plusieurs jours à faire des captures sur des multiples réseaux 1G avec Wireshark et passer ensuite plusieurs jours à retrouver ce que nous cherchions.... n’est vraiment pas une partie de plaisir.  

- **Filtrer en aval**, ce qui a la même utilité, mais qui trouve un grand intérêt quand on ne sait pas encore précisément ce que l’on cherche dans ses flux. L’avantage de notre solution, c’est que vous pouvez l’utiliser sur un Raspberry Pi pour des captures à 1G ou un celeron poussif pour de la 10G.   

- **Gérer tous les débits**, même les plus élevés, avec une simple solution logicielle. Ce qui a pour intérêt de pouvoir la déployer n’importe où sur votre infra IT. Dans notre ancienne carrière, après avoir passé 3 jours à naviguer dans un data center à faire des captures sur une dizaine de points avant de trouver celui qui nous intéressait vraiment, nous nous sommes pris à rêver d’une solution qui pourrait être déployée à distance partout sur notre infra, en quelques clics et lignes de commande sans forcément avoir à rerouter du flux ou installer des TAPs.  

Conçu pour répondre aux pain points des analystes de SOC ou des experts des CERT/CSIRT. Les analyses quotidiennes issues de ces enregistrements permettent de contrôler et d'explorer à chaud et en profondeur les évènements réseaux à partir de traces complètes et ciblées. Cela permet de garantir un réseau transparent et sécurisé, ainsi que de réduire les risques dans les environnements de cloud privé, public, ou hybrides.   

Pensé pour être capable de gérer les flux les plus complexes trouvés en Data Center et y suivre les débits les plus élevés, les enregistrements que produit n.Rewind contribuent à la gestion quotidienne de tout type de réseau, pour identifier les anomalies comme les misconfig le plus rapidement possible.  

Pourquoi enregistrer ses flux réseau ?

Etant fiers de notre culture d'entreprise et du talent de nos équipes,  nous avons décidé de leurs consacrer des pages dédiées sur le site internet de Welcome to the Jungle ;-)

Vous y retrouverez toutes nos offres d'emplois, des vidéos de certaines personnes clés de l'entreprise qui parlerons de leurs missions, etc... le meilleur endroit si vous chercher à nous connaitre un peu mieux ! 

C'est ici que cela se passe : https://www.welcometothejungle.com/fr/companies/nano-corp



Welcome to the Jungle

Au même titre que Google Cloud Platform et qu'Intel Ignite, nous avons de nouveau été sélectionnés pour faire parti d'un troisième programme d'incubation de Startup : celui d'OVH Cloud.

Cette sélection est littéralement le couronnement d'un long parcours au sein de l'écosystème de la cyber française. OVH étant par ailleurs un partenaire de choix dans le cadre de nos projets des développements souverains de notre société. 

Nous sommes donc fiers de rejoindre la promotion Terminator de l'OVH Cloud Startup Program !

![ovh.png](/uploads/ovh_963b1b6285.png)

OVH Cloud startup Program

Intel nous a invité à présenter notre startup et nos solutions révolutionnaires dans l'environnement des réseaux, devant un parterre de journalistes allemands au “Festival du Future”, qui se tiendra du 22 au 24 juillet 2022 à Munich. 

Fanch, notre CEO, y présentera sa vision du future de la sécurité et de la supervision des réseaux pour les environnements IT en complexification permanente. 

Venez nous rendre visite si vous êtes sur place !!!

https://www.festivalderzukunft.com/


Use Case

Présentation des Use Case NANO Corp

Nous avons choisi de vous présenter de manière concrète nos solutions, à travers différents cas d’usage.

Téléchargez nos brochures

Deep Observability

Smart Alerting

Live Forensics

n.Scope NDR