We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.

Let's keep in touch! Receive our quarterly newsletter by registering your e-mail.

usecaseBG.jpg

UseCase

presentation of NANO Corp's use cases

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

__Here is our two bits about one of our core fondamental value. This piece should be viewed as the white board upon which we created NANO Corp. And we wanted to share it with you !__

The article [Explosion of flows: what power is needed to supervise them tomorrow?](https://www.nanocorp.fr/explosion-des-debits-quelle-puissance-necessaire-pour-superviser-les-reseaux-de-demain/) addressed the fact that the processing parallelization inherent in hardware (like in network cards and processors, for example) provided a relevant answer to the race for speeds. But it left open the question of preserving the uniqueness of sessions in this parallelization processes.

# Complexification of networks and encapsulation
The first problem that a network (and network admin) must address is to ensure efficient and fast routing. In order to better exploit the many opportunities offered with current speeds, operators (like _TELCO_, _FAI_, _data centers_, etc.) use routers with new capabilities such as tunneling management. Optimized routing enables superior network convergence and virtualization. It then offers an improvement both in the field of **quality of service** and in **network security**, by logically separating the network into several entities.

Tunneling consisting here in **inserting protocols** into another to simplify network management by encapsulating data to new routing layers.

# What about quality of service and monitoring for network security?
Designed before tunneling became so massive, **network probes* used for monitoring were happy with processing only simple protocol sequences (also called protocol chaining) starting from the **IP layer**. They had no particular interest in dealing with low-level protocols.

For these classic probes, difficulties started to appear when it came to processing **protocols located before the IP layer**. Indeed, the explosion of tunneling has generated problems of preserving the uniqueness of sessions during the processing parallelization. In order to circumvent this problem, conventional probes have developed software and hardware solutions to access the IP layer by avoiding tunneling. The direct consequence was to blind them to Layer 2 protocols and run the risk of missing some crucial information.

# Getting rid of an analysis at the tunneling level: what are the risks?
Being able to analyze low-level protocols and in particular routing protocols, is particularly important to ensure quality of data in transit, the correct configuration of equipment and, in general, the _good health of the network_.

Nowadays, it is not possible to fully guarantee quality of service and security without also supervising low-level protocols that network equipment exchanges with on a second-to-second basis. Otherwise, the network finds itself at the mercy of how the equipments were set up after installation. If these equipments have not been properly configured, or if they have been corrupted by an attack or an unfortunate update, it is necessary to wait until  consequences on the network are sufficiently visible to note there are malfunctions.

Dealing with these protocol analysis issues only from the IP-layer and up, and not looking at what is happening below level 3 are now becoming errors portended potentially serious consequences, since they amount to depriving ourselves of both the vision over encapsulation (loss of granularity), but also over protocols dedicated to network management.

# “New generation” probes: essential allies for effective supervision
Since trust does not exclude control, it is essential to verify the correct configuration of the networks. With probes capable of exploiting **low level protocols**, it then becomes possible to have a real mapping of the **network routing** and not a theoretical mapping aligned with the configurations of the machines. For example, in the event of an anomaly, this type of probe makes it possible to precisely detect which equipment might be faulty.

It is with this in mind that the NANO Corp teams have designed a new generation of probes that can be installed both at the heart and at the periphery of networks (on the backbone or at the edge). Unlike the solutions actually on the market, these probes are not part of a logic of circumventing the problems encountered but on the contrary in an expert response to the reality of the issues.

Complex protocol chains: what are the observability challenges?

Here is our two bits about one of our core fondamental value. This piece should be viewed as the white board upon which we created NANO Corp. And we wanted to share it with you !

#Network supervision: issues have never been more important

Network supervision meets two main objectives: **cybersecurity** and **quality of service** monitoring (both in terms of integrity and performance). One technology capable of monitoring all this, is **protocol analysis**, the art of glancing at network packets. This technology, based on **network probes**, has existed since the early 2000s, when bandwidth reached a maximum of 1 Gbit/s at the maximum. Like some universities or government businesses (excluding data centers or ISPs)

## Speeds have increased almost exponentially

In the professional field, customer bandwidth steadily increased from 1 Gbit/s in 2000, to 10 Gbit/s in 2007 and then to 40 Gbit/s in 2010;

For individuals, internet speed has increased from 56k to 512k, then quickly moved to ADSL (between 1 Mbit/s and 20 Mbit/s) and finally to fiber (between 200 Mbit and now 1 Gbit. Even 8Gbit/s in France !!!).

However, the growth of computing power necessary to supervise networks has not kept up with the same rhythm as that of the bandwidth (linear growth) leading to a form of dropout.

## How ​​protocol analysis kept up with increased throughput over the past 20 years?
 
Multiplying probes could be an obvious solution to keep up with the explosion in flow rates. But, guaranteeing a correct analysis of all network traffic supposes that all the packets of the same session are processed by the same processing unit.

In order to guarantee this unity of sessions, 3 types of solutions have been developed:

- Parallelizing processes, which requires developing new parallelization chips (like _ASIC_ or _FPGA_) every time throughput increases significantly. And to adapt solutions to specific codes designed to control those chips. This makes it impossible to upgrade capabilities without changing hardware.
- Increasing computing power, which requires developing new chips with each increase in throughput. This makes it impossible to upgrade capabilities without changing hardware.
- Multiplying probes in the network which, limited to certain specific cases, is subject to location constraints on the network and can lead to loss of information.

For the last two decades, R&D work has mainly focused on the development of **hyper-specialized hardware** (FPGA, ASICS, etc.) aimed at increasing the performance of probes.

Each increase in bandwidth can only be caught up by means of major technological innovations developed over time, which explains a delay that is both chronic and “mechanical” between “old generation” probes and networks with ever denser and faster speed.

As a consequence of this structural shift, the different solutions adopted by current manufacturers led to two major drawbacks. Either costs exploded due to investments in hardware development to get more efficient probes, or infrastructure footprint exploded due to the multiplication probes in the network.

Expanding footprint or increasing cost for probes, in order to adapt to evolving bandwidth, has long remained a default solution, though. Which is now coming up against the arrival of 100G. And it’s become a sore point.
 
# 100G networks: the need to change paradigm
 
Nowadays, it is neither credible nor viable to believe in the sustainability of protocol analysis through the increase in computing power thanks to **custom hardware**. It is also neither serious nor viable to relocate network probes far from network cores. It is therefore necessary to rethink both hardware and software to meet the challenges of tomorrow.

Staying in the race requires a change of approach: using, as a base, the parallelization capabilities of conventional equipment. Network card manufacturers have placed parallelization as the standard (allowing excellent scalability). As a result, probe performance should no longer be based solely on hardware performance, but also on software performance.

An approach based on a hardware-independent library offers greater freedom vis-à-vis suppliers and guarantees quality software.
 
# Monitoring and protecting your networks : NANO’s way
 
Our network experience and our certainty in their foreseeable growth in speeds, from 100 Gbit/s today to 400 Gbit/s tomorrow, have guided us in meeting these challenges.

Years of R&D in the field of parallelization made it possible, both in terms of hardware and software, to develop our core concept : network probes offering **scalability both vertically and horizontally**.

Stay tuned for more !

Bandwidth explosion : what power will be needed to supervise tomorrow's networks?

# Deeper, Faster, Leaner

Prior to its fundraising, our company had another significant milestone: having our protocol analysis engine evaluated and validated by the leading global test and assurance solutions provider, _Spirent Communications_!

Long story short, and as Spirent said it best:

>We conducted multiple tests to evaluate and conduct stress performance across L2 to L7 with **100Gbit/s** connectivity. The aim was to validate that the performance adhered to the strict criteria of no dropped packets, transaction errors or protocol detection errors, and the NANO CORP system performed with distinction.

Spirent’s South EMEA Sales Director, Bruno Denjean

Our main objectives were to demonstrate that contrary to common belief, a new-generation protocol analysis engine can and should be developed for CPU (x86 & ARM alike) as it is the easiest solution to deploy and maintain. And what better way to test drive our engine than through the harshest trials possible as only Spirent can deliver.

As such, we purposefully chose to make it run on the most standardized computer we could find: a 32-core AMD Threadripper, equipped with only 64GB RAM, which is not a server-type processor, and no custom designed acceleration chips (neither _FPGA_, nor _ASIC_ or _GPU_ were used) to help the microprocessor.
We tested our protocol analysis engine on a fully loaded **100Gbit/s** connectivity for a variety of protocols (**L2/L7**). And we were able to meet those requirements without suffering from errors or packet loss.

To give you a taste of what our engine can do, here are some examples:

- To showcase its capabilities on **L2/L3 layers**, the engine was able to analyze precisely, with a high session rate and without any fault such complex protocol header chains as: Ethernet (4 VLANs) / MPLS / Ethernet (1 VLAN) / MPLS / MPLS / PW CW / Ethernet (No VLAN) / IP / UDP
- It never dropped a single packet at sustained **100Gbit/s**
- At lower network layers, line rate analysis has been confirmed with a high new sessions per second rate of over 13,400,000.
- At application layer, testing demonstrated the engine’s capability to properly identify various application sessions at the tester maximum capacity capability*: 750,000 new sessions per second. 950,000 new sessions per second have also easily been achieved by the NANO Protocol Analysis System with simple application traffic.

**If you want to know more, or the Spirent Report, just get in touch!**

By leveraging this new core technology and being able to get such reliable results at **100Gbit/s** on **layers 2 to 7**, our company is the only one to offer full visibility of complex networks relying heavily on virtualization and automated orchestration!

This achievement is the first step in giving back network visibility to cloud service providers, telecom operators and datacenter operators!

 Stay tuned in the coming weeks if you want to know more about our product lineup and don’t hesitate to share with us your feedback or your needs!

\*Spirent couldn’t push to more sessions per seconds that day and as such, couldn’t reach out engine’s maximum capabilities.

NANO Corp. passed Spirent’s technical tests with flying colors!

_Here is our two bits about one of our core fondamental value. This piece should be viewed as the white board upon which we created NANO Corp. And we wanted to share it with you !_

In terms of supervision and IT protection, 4 families of solutions designed to guarantee the best quality of service are historically present on the market: **Firewall**, **Network Intrusion Detection System** (NIDS), **Network Intrusion Prevention System** (NIPS) and **network monitoring tools**. The first 3 are particularly security oriented while the last one allows to go beyond this simple framework to be part of issues such as the quality control of networks or billing.

The following overview presents 4 families of current solutions and opens the perspective of answers for the future.

## Firewalls

By blocking unwanted inbound and outbound traffic, firewalls are intended to:
- Prevent basic attacks;
- Prevent network users from accessing certain sites;
- Avoid the use of protocols whose ports are (usually) fixed.

Capable of handling large or even very large speeds (**100 Gbps** and more), firewalls are limited to simple processing rules. The latter are very often based on a simple correlation between the IP and the port, sometimes a REGEX (ie. regular expression) simple in the data (payload) is also taken into account. This simplicity explains their lack of precision.

Traditional firewalls do not make protocol classification. However, some may embed NIDS within them in order to propose the writing of more precise rules (e.g. instead of blocking the entire web feed, we will only block a particular site). Nevertheless, the flows then treated are significantly lower.

In summary, firewalls are able to take into account large speeds with a small footprint, but with very limited protection features. They are definitely not able to do much by today's standards. 

## Network Intrusion Detection System (NIDS)
Generally limited to speeds of the order of_ 10 Gbit/s_, this tool is intended to warn network managers of events of malicious origin. It is based on a more in-depth analysis of the contents of the packets than that of the firewall. It is generally able to decode and use the information conveyed by major protocols (HTTP for example).

Its alerts are based on more complex and advanced detection rules than those of a firewall (mostly SNORT rules). They can be very accurate when they rely on known protocol fields (Host field of the HTTP protocol for example). They can also be much more general and then very similar to those of a firewall. These specificities give the tool a flexibility and precision that the firewall does not have.

In summary, NIDS are able to warn network managers more accurately than a firewall, but are unable to block unwanted flow. Unlike firewalls, the rates supported by NIDS are greatly reduced.

## Network Intrusion Prevention System (NIPS)
This tool is nothing more than a merger between a firewall and a NIDS. It therefore makes it possible to block traffic more precisely than a firewall. Despite these particularly interesting functional characteristics, NIPS does not solve the problem of low throughput supported by NIDS.

## Monitoring tools
Monitoring tools allow monitoring, usually delayed, of the state of the network. These tools are available in two main families.

The first, called specialized, is made for the in-depth study of specific business protocols. It is limited to low speeds (1-10 Gbit/s) and is intended to provide a comprehensive view of certain parts of the network.

The second, more common, is made for a cursory study of the network by means of summary statistics on the sessions viewed (when you are lucky to get even that). It is usually integrated with network equipments (mainly routers) and supports higher speeds (up to 100 Gbps). But most are proprietary. Though it can, if necessary, make a brief sampling of the packets passing over the network (of the order of one packet out of 10,000) to give you a little bit more info.

In summary, monitoring tools are able, depending on their family, to provide a (barely) fine but partial view of the network or an overview but not very detailed.

# A common engine: protocol analysis
The tools previously discussed all need to identify and extract information from communication protocols. There are different ways to approach this analysis: it can be succinct and fast like the one performed in firewalls or more accurate and slower like the one found in NIDS.

The brief analysis is based solely on the ports in order to “identify” the protocols, which implies many false detections. The in-depth analysis, on the other hand, dives into the heart of the packets in order to recognize the signatures of the protocols which theoretically offers a very good level of confidence.

In addition, this deep analysis involves many calculation operations which limits the supported throughput. In addition, to guarantee suitable flows, it deliberately closes its eyes to the increasing complexity of the networks and is limited to the beginning of analysis from layer 3 (non-management of tunnelling).

In summary, it is indisputable that protocol analysis is vital to network supervision. It is also undeniable that the reliability of current solutions is hampered by the explosion in flows and the increasing complexity of networks.

# NANO Corp: next-generation solutions for monitoring your networks
With revolutionary protocol analysis technology, NANO Corp solutions complement and enhance the current tools in place on your systems.

Network supervision: what equipment choices are available to you?

Cybersecurity requirements are constantly increasing and becoming more stringent, whether because of an attack (DDOS, ransomware, etc.), a shift of standard (25/50/100 Gbit/s) or to adapt to legislative changes (NIS2, Cyber Resilience Act, etc.). If for a while CISOs were able to simply install an IDS/IPS, today they must choose more effective solutions in complex technical and regulatory environments. 

 

This has had an impact on the solutions market. Once a vector of major innovations, it has become bogged down in fads and rearguard battles and has allowed press releases and bought articles to outweigh the reality of declining technological advances. 

 Each year the media ecosystem looks for its new champion and over time the focus has shifted from IDS to IPS and from UTM then to SIEM. Recently, development efforts have focused on the endpoint and around end users (UBA - User Behavior Analytics). Thus, EDRs, and more recently XDRs, have been put under the spotlight by the commercial narrative. Those who seek to see more clearly are confronted with a plethora of comparative articles that attempt to separate the best players on the market through a very fine analysis grid, even though their technological principles are identical. 

 The common feature of these products, all of which are excellent, is that they have significantly enhanced their threat detection and endpoint protection capabilities through the deployment of software agents. However, this machine-centric approach to cybersecurity provides only partial protection and still has large grey areas and, in any case, will only work for known threats, on an identified pool of machines capable of supporting an agent. 


# Agents as champions of cyber security solutions?

The reason why agent deployment is so widespread is because it addresses a growing need for improved visibility across all endpoints. EDR solutions are also well suited to detect and protect your IT assets against some of the advanced forms of threat (malware, APTs, phishing attempts, etc.) that have never been more prevalent than since teleworking became widespread. 

However, to carry out their mission, agents are constantly requesting privileged access to your resources and systems. Some may, for example, send the contents of your email databases unencrypted to a cloud, over which you have no visibility, others to apply NLP (Natural Language Processing) algorithms. Some will periodically scan the RAM of your machines and your entire file system to be able to fight against threats that are becoming increasingly sophisticated to evade EDR detection techniques. 

The changing nature of threats requires increased resources to counter them. However, the deployment of agents in a computer park is a committing act.  In some cases, agents can become privileged access points to all your information systems (# SolarWinds). 

 Once an EDR/XDR is subverted or a NIDS bypassed, the ability to be notified that a network is being invaded and that data may be exfiltrating is significantly reduced. Furthermore, while EDRs work well on machines running traditional operating systems (Mac OS, Windows, Linux), their effectiveness is questionable in more exotic environments such as IoT, industrial equipment (SCADA) or BYOD environments. 


# Why is EDR still the big favorite of CISOs?

If the deployment of agents continues to multiply exponentially, it is both because it is simple: one machine-one agent, and because the intensity of the sales pitch can give the illusion that this is enough to protect the whole IT infrastructure.   

This is compounded by the inability of known network security players to provide technically powerful and affordable solutions that offer granular visibility into the network. 

Solutions such as NDR (Network Detection and Response) exist but are unable to keep up with network changes. Indeed, to hide their obsolescence, they mostly use technical shortcuts, incompatible with a Zero Trust approach (such as packet slicing, packet sampling, exclusive_over_IP, FPGA, etc.), while having a very high physical footprint and financial cost. 

The traditional approach to network analysis has not been able to cope with several important developments: 

- Continuous increase in speeds (25Gbit/s, 50Gbit/s and now the widespread deployment of 100Gbit/s); 
- Diversification of uses (BYOD, IoT, etc.); 
- Increasing complexity of networks (encryption, increasing virtualisation, GSM over Ethernet, etc.); 
- Hybridisation: core to edge, edge to cloud, edge to edge 

This is how EDRs naturally became, both technically and commercially, THE solution. In other words, the only solution. Technically, because it allows the difficulties to be circumvented by shifting the responsibility for security to the end point, to the users, so to speak. And commercially, because selling many subscriptions at a low unit price is easier than convincing a company to invest in equipment that is more expensive, unit-wise, but which will enable it to obtain the full visibility it needs. 

In a Zero Trust approach to cyber security, the EDR is of course still relevant, but it is only one brick in a larger architecture. **It cannot therefore be the alpha and omega of the security policy of an information system. No cybersecurity solution can or should claim to be...**
![ILLUSTATION-EDR-NANO.png](/uploads/ILLUSTATION_EDR_NANO_d3dcd0272b.png)
EDR is a necessary tool, but it is not the whole package... 

# An NDR yes! But in Zero Trust mode! 
As mentioned above, network analysis and security solutions are already trying to solve certain cyber challenges that could be part of a Zero Trust approach, which poses the framework of not trusting anything outright: everything is checked, from infrastructure to usage, at all times, not just access rights. 

Yet, network security solutions are generally all undermined using hardware and software shortcuts that require them to place total trust in elements that they do not control (e.g., such as settling for visibility only on certain protocols over IP) or to use statistical "tricks" to compensate for their inefficiency (sampling, slicing, etc.). 

The mirage of statistics is a striking example. Some marketed solutions apply Machine Learning (M/L) processes for detection. The problem is that it is inaccurate and risky to base one's M/L on statistical values that are themselves derived from uncontrolled sampling, not to mention the toll high false positive rates has on SOC teams. In any case, it is not possible to comply with a framework inspired by Zero Trust (which is itself being increasingly abused for marketing reasons). 

 The use of Machine Learning to reinforce advanced detection and alerting capabilities and to warn the user of complex anomalies linked to the misuse of applications and processes is conceptually satisfactory, but only if its limitations are known. Based on fragmented data, it cannot claim to be exhaustive and to be able to observe the networks completely. The same is true if one confines oneself to network analysis over IP flows or even only over_TCP! 

 If observability is not complete, it is like analysing an iceberg by being satisfied with the emerged part: the submerged part remains in the shadow.  By giving up this capacity, we allow networks blind spots to persist, which are constantly multiplying with the generalisation of virtualisation, Shadow IT, BYOD, etc... 

 In addition, even with very high-performance NDRs (such as Extrahop or VectraAi), the obligation to use specific hardware makes them, by definition, not very scalable and locks them into a very restrictive usage framework.  

 Unfortunately, the software version of their application suite, due to its poor performance (ratio of resources required to flows processed), causes an explosion in hosting costs. This very limited performance is pushing them further and further away from the Zero Trust they claim to be. 
 
 # What should a CISO do to increase its protection, reduce and control its attack surface? 

 Obviously add an NDR to your suite to complete your EDR. But an NDR capable of Zero Trust Traffic Analysis (Z2TA), i.e. a complete analysis of each packet on all layers and capable of extracting all the necessary metadata (which excludes sampling-based technologies). 
 
Z2TA forces us to start from a blank page in order to respond to all of the problems previously outlined and allows us to offer CISOs uncompromising visibility, i.e. without conceptual bias, of their networks. Z2TA is the solution of the future that allows to counter a set of threats that EDRs are not able to see, and of which they are sometimes the vector. 

Zero Trust Traffic Analysis is an indispensable tool in the CISO's toolbox to meet the highest cyber security requirements. 

EDR : Beyond the hype

# NANO Corp. At VivaTech !

Thanks to [Intel Ignite](https://www.linkedin.com/company/intel-ignite/) and the incredible opportunity they are regularly giving us, NANO Corp will be at Viva Tech for it’s 2022 edition!  

We've got an e-booth check it out and we'll be there to show you our mettle on demo day, Thursday! 

You can check us out through this [link](https://app.vivatechnology.com/session/3c5bfa00-08e7-ec11-b656-a04a5e7d2a9d ) if you want to see our CEO have a live talk!

Edit : if you want to see our CEO making his pitch, it's just below!

NANO Corp. At VivaTech ! 

# Clickhouse  meetup

If there was just one reason why we love [ClickHouse](https://www.linkedin.com/company/clickhouseinc/) I'd say it's because we can actually change the world with it.  

Simple as that.  

Do you want to know how? Come and listen to our founders as they explain everything during this conference at Content Square. 

This is where it's happening: [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)

Clickhouse Meetup!

# FIC 2022 is over!

Job done!
 
Thanks to the whole NANO Corp team, to the CFI jury, thanks to the [FIC (International Cybersecurity Forum)](https://www.linkedin.com/company/forum-international-de-la-cybers%C3%A9curit%C3%A9/), thanks to [Atos](https://www.linkedin.com/company/atos/) and the [European Cyber Security Organization (ECSO) ](https://www.linkedin.com/ company/ecso-cyber-security/)

You can be sure that this award is the first in a long line of futur awards!

Thanks also to all those who came to visit us at the cocktail party and celebrate with us the Cybersecurity for Industry award!

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

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

International Cybersecurity Forum ed. 2022

# Google for Startup Accelerator chose NANO Corp.

Have we told you how proud we are of our team ? Probably a quite few times already. 
 
Well, here is one more reason: 
 
Hundreds of applicants, 13 selected, 1 french company only -> NANO Corp 
 
With [Google Cloud](https://www.linkedin.com/company/google-cloud/) we will focus our work on cloud ops and machine learning to provide our network observability solution to Google Cloud and their clients. 

If you want to know why we got selected for GCP's first time in Europe, the best is to see what Google says about us : [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 ) !

1st Google Cloud Startups Accelerator in Europe

# Come see us in numbers! !

Want to talk to network experts ? 
 
I know where to find them, at the FIC (International Cybersecurity Forum) on NANO Corp's booth E1-16 ! 

There will be a cocktail on NANO Corp's booth E1-16 at 5:30PM. Come celebrate our Cybersecurity for Industry award with us!

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


We will be at the FIC 2022!

# NANO Corp. got the Cybersecurity for industry #2022 award!

Is it a smile? Yes it is! NANO Corp won the Cybersecurity for Industry award of the [FIC (International Cybersecurity Forum)](https://www.linkedin.com/company/forum-international-de-la-cybers%C3%A9curit%C3%A9/)!

As the very first recipient of this award we are challenged to contribute to making as prestigious as possible! 

Want to know more? Come meet us at booth E1-16, in Lille, from June 7 to 9.


![Two happy people from Nano Corp after they got the CFI Award](/uploads/Prix_du_CFI_8ead9a09c4.jpeg)

CFI (Cybersecurity For Industry) award 2022!

# NANO Corp. joins the Intel Ignite program for startups!

I had mentioned a few weeks ago an important upcoming announcement.     

The information is now official: NANO Corp is selected to take part in the [Intel Ignite](https://www.linkedin.com/company/intel-ignite/) Europe startup growth program!  
    
NANO Corp is very proud to have been chosen, after a rigorous selection process, in one of the most challenging and competitive accelerator programs in the world.  
 
Intel Ignite is [Intel Corporation](https://www.linkedin.com/company/intel-corporation/)’s program for deep-tech #startups who have a bold and innovative technology that will disrupt their industries.  
 
Through mentorship, technical support, and business acumen, Intel boosts the startup capacities and allow them to reach new heights!  
 
Feeling ignited!

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

https://intelignite.com/program/

Intel Ignite & NANO !

# NANO Corp. joins the ACN

After taking the time to look at the different frameworks of expression, we have chosen to join the [ACN - french for Alliance for Digital Confidence](https://www.linkedin.com/company/alliance-confiance-numerique/) to convey our beliefs in cybersecurity.

We are eager to participate in the first information meetings and to meet the other members!

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

We join the ACN

What more can we say, except that we are proud to be able to join all the members of the French Cyber Center for Excellence!

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

Joining force with the French Cyber Center for Excellence

# FIC Award?

Yesterday I announced the selection of NANO as a DeepTech startup, today we are proud to be pre-selected for the FIC award. Many more announcements to come in the next few days...

For the occasion, our CEO Fanch FRANCIS was interviewed by the jury before he pitched all our projects to the comity ! (it's in French only, I'm afraid)



We will of course be at the FIC2022, where we hope to see you all !

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

Pre-selected for the FIC Award !

# Deep Tech Recognition

NANO Corp. has been recognized as a **Deep Tech** startup by the BPI (Public Bank for Investment in France).

Beyond the financial aid, this recognition by a panel of network experts reinforces the decision taken by the founders of Nano Corp to always be at the forefront of research in the field of network security.

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

BPI gives NANO the Deep Tech label

# NANO Corp. at European Cyber Week

We are honored to be counted as a partners for the 6th edition of the [European Cyber Week](https://www.linkedin.com/in/ACoAACe4a5MBX9AH_jnPkIJf2UzpW9QTYGZzw6U).
 
We will show you the fruits of our developments: network supervision and packet capture  tools for telecommunications operators (ISP)  providing full observability over all network traffic, from core to edge, so users can finally control all their network flows in a comprehensive single pane of glass.
 
If you want to meet us, we will be on our stand at the Couvent des Jacobins in Rennes, from November 16 to 18, 2021!

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

European Cyber Week 2021

# Some of our reservations about the DPDK 

 Our first set of RUST drivers, for Intel 1G, 10G and 40G boards is finished (we'll write a bit more about it, but our benchmarks are really brilliant!) We run them in userspace, like our probe!  
 A question we were asked quite often during the last FIC (2022) was: 
 >"Why didn't you use the DPDK?", 
 
 Understand: 
 >"Apart from a masochistic side, is there a valid reason?  

 When **Intel**, inventor of the DPDK, chose us to be one of the 10 startups to be accelerated in their **Intel Ignite program** in 2022, we were asked the same question over and over again by our interlocutors.   
 It is now time to express the reservations we have about DPDK in our context and the reasons that motivated us to choose another path.  

The answer to this question could be summarized as "_we do everything in **RUST**, we are so used to suffering that developing our own NIC drivers was just another walk in the park, on fire_". So, yes, there is definitely an attraction to pain.   

 On a more serious note, the reality is that when we developed our network probe, with the goal of reaching **100Gbit/s**(https://nanocorp.fr/en/nano-corp-passed-spirent-s-technical-tests-with-flying-colors/), we found that using the DPDK caused many problems. Especially when our goal was to analyze networks for cyber security purposes.  

 The DPDK is a rather revolutionary open-source technology. It was initially developed, then proposed, by Intel for Linux environments. Its objective is to provide Data Plane libraries and drivers to manage network cards.  

  For those who are not familiar with the DPDK, this technology appeared in 2010 and came to dust off the existing Linux network stack, which was aging and really not very efficient.  


## How does DPDK works ?

 At startup, a network software calls the kernel to configure a packet acquisition method. Several technologies exist, the most popular of which are certainly **AF_Packet** (native in Linux), **AF_XDP**, **DPDK**, or **Netmap**.  

 With DPDK, the kernel will be bypassed entirely by default and a different driver will be used, in charge of the management of the network card. This has allowed the DPDK to quickly establish itself as a replacement for the traditional **Kernel/Linux** networking stack.  

 The DPDK uses several strategies to achieve maximum performance. The DPDK's allocation of dedicated CPU cores guarantees better performance of "network applications" (in terms of processing millions of packets per second). The "**hugepages**" ensure a more uniform access to memory resources (**memory pool**) in time, which reduces the number of "**TLB misses**" (**translation lookaside buffer**). There are of course many other optimization techniques (we can mention the recovery of packets by batch, or the bypassing of the kernel which also induces a reduction of copy/recovery operations at the buffer level).  

 In general, the reduced load on the processor often allows to obtain interesting performances. And as Intel points out, 
 >"_The DPDK removes some of the bottlenecks involved in packet processing. By moving memory buffers into user space and performing polling rather than interrupt-based processing, the DPDK is able to improve performance with small packet sizes._" 
 >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).  

 Today, in a hypervisor environment, thanks to the use of the DPDK, **Open vSwitch (OVS)** and Virtual Function Management, it is possible to benefit from several interesting optimizations, especially in the case of inter-virtual machine packet transmission (i.e. **VMs** on a single physical machine).  

 So, why do you punish yourselves, might you ask ?  

 During our experiments, we noticed that the DPDK also had certain limitations that heavily impacted the performance of solutions based on protocol analysis. Among these limitations, we have identified 4 main ones that made us decide not to use this technology for our solution: 
- compiling/maintainance challenges,  
- configuration/deployement difficulties,  
- absence (to date) of RUST compatibility,  
- framework which imposes to have its own threads.

The latter implies that it cannot be used only as a package reading backend. A solution using DPDK can only use DPDK, but we wanted to have a broader compatibility. 

These are not the only constraints or limitations we encountered, although they were decisive in our abandonment of this technology. Among the other points that irritated us, we could mention the following examples.  

DPDK is a complex framework to maintain because of its legacy systems, which makes it even more difficult to adapt for complex network environments. 

 When DPDK is updated, there is a loss of compatibility with previously compatible hardware. 

The implementation at the level of the network interface cards is complex.  

DPDK manages its own threads, which are externalized from the kernel. It therefore has its own scheduler. And as it is initialized at boot time, it is not possible to make changes except by rebooting the whole system. This has an impact on the dynamic scalability of any solution built on DPDK.  

In research and development work, we have never been able to maintain 100Gbit/s throughput (148,800,000 packets per second) with small packet sizes (64 bytes) with DPDK despite announcements made on this performance by the community. We tried this on several different network cards. 

The network card drivers implemented in DPDK have their own threads (of CPU cores), which sometimes leads, depending on the use case, to call-back systems that can cause a significant overhead on processor resources when registering packets in PCAP.  

And finally, we have noticed a plateau when certain DPDK-based solutions must use more than 30 cores. 

We’d like to stress that these points may however evolve, DPDK being regularly updated, some may be resolved since the last we tried DPDK implementation. 

NANO Corp's goal is unified observability, i.e. the ability to monitor both physical and cloud networks with the same platform. The development of our cloud probes (spoiler alert: big announcement coming soon) required us to anticipate the potential impacts of DPDK in these environments.   

 Although we have not experienced this due to other development choices, in virtualized environments it has also been noted that the DPDK may have difficulty making packet handling scalable. As stated here:
 >"_OVS-DPDK performs very similarly in our test environments, scaling linearly for initial VNFs, but then reaching a plateau in system throughput as more VNFs are added. We show that this plateau is a function of the CPU resources allocated to the virtual switching functions of OVS-DPDK_." 
 >Pitaev et al., 2018 Characterizing the Performance of Concurrent Virtualized Network Functions with OVS-DPDK, FD(.)IO VPP and SR-IOV. 
 
 Thus, we were concerned that the more virtual machines the hypervisor had to manage, the faster the protocol analysis solution would be saturated. This hypothesis was confirmed during our research. A saturation that it was not relevant to try to circumvent until this technology had evolved.   

 It is in the light of all these reservations that we decided to bypass the DPDK and to redevelop a solution working entirely in userspace, including NIC drivers. Article to come on the subject.  

 If you have encountered similar problems or if you do not share this analysis, our researchers and in-house developers will be happy to discuss with you on the subject.  

Please reach out, we’d be happy to discuss! 

Some of the limitations we hit with DPDK

# Analysis of network packets with an FPGA.

Many network probe vendors have turned to FPGAs over the past decade after their software solutions reached hardware limits. This approach was intended to help them overcome the increasing complexity of networks and their inability to keep up with bandwidth. 

We don’t want to disparage FPGAs, because this technology has a proven track-record bothf for performance and quality. However, our experience has shown that in use cases like network packet analysis for cybersecurity purposes, this technology does not necessarily meet the requirements of a Zero Trust framework. Which implies a complete processing and analysis of absolutely every packet, on every layer. A much-needed requirement when security must take into account a progressive shift to the Cloud.  

In the case of network analysis, FPGA limitations should be put into its own context, that of new challenges such as **an increasing usage of virtualization or tunneling protocols**, requiring network monitoring solutions to decapsulate all lower protocol layers. In addition to this problem, there is also the problem of [complex protocol stacking](https://nanocorp.fr/en/complex-protocol-chains-what-are-the-observability-challenges/) and the constant evolution of networks, as new protocols appear regularly while there are already a multitude of them! 

Our arguments on judging FPGAs to be imperfect for network monitoring and cybersecurity are both technical and commercial. 

# Technical arguments

As a reminder, an FPGA (which stands for Field Programmable Gate Arrays) is basically a chipset composed of a multitude of Arrays that can be reprogrammed after manufacture (which is not the case for a CPU). Therefore, it is possible to configure these Arrays and to define their interconnection points, to answer for a given purpose. While a CPU is able to execute billions of instructions during thousands of cycles, depending on what is required of it, an FPGA can achieve the same result in far fewer cycles. To make it simple, an FPGA is like a CPU you can custom as many time as you want to do one thing. It might do that thing far better than a CPU. But it will do just that thing. There is no polyvalence to an FPGA, it’s a bit of a one-trick pony technology. It has its advantages, but also many drawbacks.  

Ideal in the automotive industry, finance or in network environments (LUA chips), it becomes more difficult to use FPGAs when the problems you wish to address have solutions that can only be implemented with complex entanglements of conditional data processing.  

In those cases, our experience shows that FPGA is no longer able to deliver the expected performance. Especially when we needed to develop specific processes built on sequences of parallelized conditional nesting (algorithms based on complex and recursive decision trees, for example). 

FPGA is usually very efficient when a set of conditions need to be tested simultaneously. This makes it an excellent tool in network signal processing, for example (Layer 1 of the OSI model) or when it comes to parallelizing some processes. 

On the other hand, in a network use case based upon layer 2 to 7 and when the number and diversity of protocols to be classified become too complex (multiplexed protocols, complex protocol stacking, etc.), **FPGA-based solutions will generally not be able to classify protocols that do not announce themselves.** This results in increased inaccuracy and loss of visibility. 

Among the reasons that made us realize FPGA has too many technical limitations in the field of network observability, here are the ones we considered the most striking or limiting: 
- FPGA didn’t perform well on sequential parallelization of dynamic conditional loop, which lead to focusing exclusively on processing select few low-level protocol layers. Network protocols that correctly announce the protocols that follow them (and the more dynamically and imprecisely the protocol layers stack up, the less relevant FPGA becomes). **Beyond Layer 4, it’s not possible for FPGA to correctly classify network protocols**. Similarly, network virtualization protocols (like VLAN or VxLAN), if even identified, are only processed for a given number of iterations. This makes deploying such solutions in core networks, such as that of a data center, far less relevant. 

- Its identification is very limited for high protocol layers and for unannounced protocols. **It is very difficult to create complex filters with FPGA**. Many solutions are satisfied with handling only a few lower layer network protocols and only under certain conditions (MPLS if it is the IP protocol that follows it, or VxLAN, but on ports only). 

- Networks have become very dynamic, and it is not uncommon to see some aberrations in terms of network stacking (virtual or physical), especially in hybrid environments. Because FPGA is almost stateless, **it is difficult to identify protocols correctly when it’s necessary to hold several packets**, especially when the throughput is high and the NIC's memory is limited. 

- FPGA will have **increased difficulty with de-encapsulating successive stacking of tunneling and multiplexed protocols**.  

- FPGAs are not agile. Network protocols are not immutable. They are constantly changing and it is not uncommon for them to evolve or for new protocols to appear. Because **time-to-update for FPGAs is higher than any other approaches**, they will always have difficulties handling unknown errors. 

- A solution "compiled" for** FPGA will not work outside the same FPGA NIC of the same manufacture**r. 

- At a time when more and more applications are migrating to the cloud, it is still impossible to virtualize FPGAs, which makes one of **the major advantages of the cloud, namely its scalability, incompatible with any FPGA based solution**. 

While FGPAs can respond to some narrowly defined visibility issues, its approach is not Zero Trust since it accepts sacrificing observability in favor of processing higher volumes of data. 

# Business arguments

Our solution, Zero Trust Traffic Analysis, addresses all the technical issues outlined above. But mirroring those issues, It also allows us to build a solid business case around the following technical realities: 

- **FPGA is said to be "Vendor Locked" as well as "Technology Locked"** (It becomes impossible to transfer your protocol analysis solution to another remote server if it does not have the same FPGA chipset or an exactly equivalent hardware characteristics)  

- **FPGA prohibits any form of scalability** except through the purchase of additional hardware (you want to increase throughput or add interfaces, you have to pay again). 

- Semiconductor **shortages have even more impact on specialized chips like FPGA**

- An **FPGA solution generates a higher TCO** (Total Cost Ownership): a powerful, expensive server and several FPGA chipsets are essential for high density environments (Data Centers). Which goes contrary to environments where overhead is to be banned 

- Orchestrating **network analysis solutions built for CSP/Data Center architectures is impossible**.

After reading these arguments, we hope we’ve convinced you, or at least opened your mind.  Our words may seem inflammatory. But they are not. FPGA is still a great tool for many use cases.  

Yet, we feel that FPGA is not well suited for network protocol analysis in the cybersecurity field because using it is restrictive and deployment is limited to proprietary infrastructures. Moreover, networks are bound to become increasingly more complex (new uses) and infrastructures to become hybrid (shift to the cloud). In this context, the only approach making sense will be to favor very high capabilities for adaptation and greater integration.  

The very same approach chosen by NANO Corp. 



Using FPGA for Zero Trust network packet analysis, not the best idea! 

Since we are really proud of our corporate culture and of the many the talented people in our team, we finally decided to devote a full page to them on "Welcome to the Jungle" website ;-)

You will find all our job offers over there, some videos of key people in the company who will talk about their missions, etc... it's the best place if you are looking to get to know us a little better!

This is where it happens: https://www.welcometothejungle.com/fr/companies/nano-corp



Welcome to the Jungle

# Why should you record your network?
**And more importantly, why do it with our solution, n.Rewind **
![Sans titre.png](/uploads/Sans_titre_df8fe95079.png)

## PCAP or it didn’t happen!
**The cyber combatant reflex card.**

Known as PCAP (for Packet CAPture, the best-known network data logging format), capturing network traffic is common practice for both network administrators and cybersecurity specialists. 

A PCAP file is a record in binary format (with ~20-30% overhead compared to the original stream). It provides full visibility of past events. It allows complete snapshots of the network to be taken for analysis. 

In other words, it’s your networks replay, rewatch your favorite episodes such as _Tuesday's DDoS_ or the _Ransomware Special _or the _DHCP Malfunction Show_ 

Without a timely PCAP trace, it’s not possible to perform an efficient forensic analysis. Here arises the challenge n°1: how to make the capture in time? 


## PCAP, what for?
**Anything and everything.**

A PCAP serves as a basis for analyzing and helping to monitor the health of the network (e.g., ICMP flood or lag at TCP session level), but also to detect anomalies and malicious activity. The PCAP allows to trace the origin of the problem you want to identify on the network. 

Supervising the source or destination of traffic, identifying data from "applications" and devices, detecting the origin and causes of malfunctions (which can also be indicators of compromise, or IoC), etc. 

Overall, there are four main categories of packet capture usage: 
- **Identify** congestion points: thanks to the capture, it is possible to observe the path of all packets, which can help to identify congestion points, 

- **Troubleshoot**: the granularity of the PCAP (i.e. having all the packets) is the ideal (though very time-consuming) solution to identify precisely a problem and its root cause, 

- **Explore**: an essential component of forensics, the PCAP is often essential for identifying or confirming the presence of malware, detecting malicious behavior and security flaws, 

- **Keep evidence**: the PCAP allows you to share a consistent, complete, disseminable record of a network event. 
To be useful, a PCAP must both allow the entire event to be recorded, but also remain usable (exploration time/size of the recording). The larger it is, the more complete it is, the more time is needed to isolate the elements of interest. This brings us to challenge n°2: how to get a targeted capture?

## Is PCAP easy to do?
**Childish.** 

Unless: you're in the cloud or in hybrid or high-speed environments, under a demanding SLA, or under attack. Yep, apart from your normal day in a SOC it’s super easy to do. 

A Tier 2 SOC analyst assists in the remediation of cyber-attacks by collecting host and network data for further analysis and triggering appropriate security measures in accordance with the incident response plan. The main issues it will face are: 

- No or incomplete or too much information about what happened before and after the cyber incident 

- Even if forensic data is available, it can be very large, expensive to store and extremely time-consuming to explore and analyze manually 

- In the midst of an incident, it can be complicated to make a useful capture and to switch between tools to analyze the packets. 

As you can see, challenge n°3: how to make a capture in the heat of the moment?

## Does size matter?
**Oh yes! And usage too!** 

If you want to do core capture, the size of PCAPs will often exceed the capabilities of the tools used to capture them. Furthermore, it will be difficult to collect complete conversations (or sessions) because your capture tool is not powerful enough. This is why we recommend that you consider the stream-to-disk rate, a metric that is particularly important to pay attention to in environments with data rates above 10Gbit/s. It is not uncommon at high bitrates for capture tools to claim performance that they are only capable of delivering in a handful of seconds. A limitation that some are not afraid to market as a feature, called "microburst". 

Conversely, if the capture is done at the edge of the network, visibility will be limited. And we may miss the detection of a DDoS or malware. 

The confluence of these constraints has given rise to a common quote that we often hear from some of our clients: "Sometimes I spend two to three days to find what I’m looking for in the extract. This really underlines the “needle in a haystack” principle. And no you can’t burn the haystack and go through the ashes with a magnet as our cheeky intern would say. 

And this recurring problem is not going to go away as enterprise network speeds increase. Wireshark is already unable to record 1Gbit/s network streams without packet loss. But already some ISPs are offering 2.5Gbit/s customers and others 8Gbit/s (even if their offer is marketed at 10Gbit/s). Data centers are moving from 40Gbit/s to 100Gbit/s and 400Gbit/s is expected to be widespread by the end of this decade. Performing packet capture in these environments is no longer possible with current tools and hardware. 

Therefore, challenge n°4 : how do you find the needle in the PCAP haystack? 


## 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)

**Intelligent packet capture**

As mentioned above, security specialists face 4 challenges limiting their ability to benefit from a useful trace: 

- Challenge 1: how to do the capture in time. 

- Challenge 2: how to make a targeted capture. 

- Challenge 3: How to capture in the heat of the moment. 

- Challenge 4: how to find the needle in the PCAP haystack.

These challenges are worsened with the constant evolution of networks (core to edge, edge to cloud, edge to edge), with hybridization and the acceleration of throughputs. RIP tcpdump. 

**n.Rewind** is the customizable capture tool that we have designed to meet all of the above challenges. It allows for full or filtered, automated capture and includes a buffer to make sure you don't miss the start of the show. 

To do this, we started from scratch and realized that only our network probe technology could provide a new answer to this recurring set of problems. The application of our probe technology on the capture allowed us to: 

- **Benefit from a buffer**, (where the size depends on the allocated RAM), which allows you to go back in time and record the "network moments" that precede its triggering, useful for cyber security analysts looking to understand the attack path or weak signals specific to an activity. 

- **Perform automatic captures** triggered by filters or APIs. 

- **Upstream filtering**, i.e., on the core network at 100Gbit/s. With a set of filters that is much more precise and more useful than the 5-tuple and that considers some complex protocol stacking like tunneling, multiple VLANs, MPLS, etc... A very efficient way to get a lightweight PCAP when you know exactly what you're looking for in big pipes. Just like our previous experience, spending several days capturing multiple 1G networks with Wireshark and then spending several days finding what we were looking for.... is really no fun. 

- **Downstream filtering**, this has the same use, but is of great interest when you don't yet know exactly what you are looking for in your streams. The advantage of our solution is that you can use it on a Raspberry Pi for 1G captures or a sluggish Celeron for 10G, and 5 to 10 smaller than the competition for a 100G. 

- **Handle all data rates**, even the highest, with a simple software solution. This has the benefit of being able to be deployed anywhere on your IT infrastructure. In our former career, after spending three days exploring a data center, taking snapshots at ten or so points of capture before finding the one we were really interested in, we started dreaming of a solution that could be deployed remotely anywhere on our infrastructure, with just a few clicks and command lines, without necessarily having to re-route flows or install TAPs. 

Designed to meet the pain points of SOC analysts or CERT/CSIRT experts. The daily analysis of these records allows for in-depth, on-the-fly monitoring and exploration of network events from complete and targeted traces. This is essential for a transparent secure network and to reduce cyber risk in private, public, and hybrid cloud environments. 

Built to handle the most complex flows found in data centers and to track the highest throughputs, the records produced by n.Rewind improves incident response times as well as the day-to-day security operations of any type of network. 

Do you want to be sure you’ll never miss the show ? Reach out, and try our network replay tool.

Why you should record your network traffic

Along with Google Cloud Platform (GCP) and Intel Ignite, we have once again been selected to be part of a third Startup incubation program: OVH Cloud's.

This selection by OVH comes as a crowning achievement along an arduous path, albeit fruitful, within the French cyber ecosystem. OVH being definitely the best partner we could find in the context of sovereign developments.

Therefore, we are proud to join the Terminator Promotion of the OVH Cloud Startup Program!

Stay tuned to hear even more in the foreseeable futur!

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

OVH Cloud startup Program

Intel Ignite invited us to show what's making our startup and our solutions so revolutionary in the networking environment. And to do it in front of an audience made up of German journalists at the "Festival of the Future", which is held from July 22nd to 24th, 2022 in Munich.

Fanch, our CEO, will talk about his vision for the future of network security and monitoring in increasingly complex IT environments.

Come visit us if you are in the neighborhood!!!

https://www.festivalderzukunft.com/