Security Researchers: Digital Fighters Series
Astelia: “Vulnerability does not exist on a server alone”
Yuval Barak, Founding Research Engineer at Astelia, discusses how AI is solving the historical challenge of knowledge transfer as part of CTech’s Security Researchers series.
“I was always a nerd. As a teenager, I would stay at school until 11pm building robots and writing code that I could probably just download from GitHub, if I had known about GitHub when I was 14,” says Yuval Barak, Founding Research Engineer at AI cyber startup, Astelia. “At 16, two of my friends and I won an international robotics competition in Connecticut, which was probably the first time I realized that spending endless hours obsessing over technical problems might actually be a useful skill.”
Within Israel’s cyber companies are small, highly specialized teams trained to think like attackers, find vulnerabilities and stay ahead of a threat landscape increasingly accelerated by AI. In this series, we meet the individuals and teams who make up this frontline of cyber: the digital fighters.
Reflecting on his “Moby Dick” in the security research field, Barak explains it is “the moment when the industry will finally understand that a vulnerability does not exist on a server alone.” He continues: “It exists inside a network, behind controls, and along a path an attacker may or may not be able to take.”
You can read the entire interview below.
ID Card
Company name: Astelia
Founders: Alon Noy (CEO), Nadav Ostrovsky (CTO), Roy Rajwan (CPO)
Year of founding: 2024
Current number of employees: 53
Company Description:
Astelia is an AI-native exposure management platform built by the leaders of Israel's National Red Team. Traditional vulnerability management hands security teams a list of millions of findings ranked by a generic severity score. We model the customer's actual network: topology, segmentation, security controls, and the reachability of every asset down to the individual port, and then run AI agents to determine which vulnerabilities are genuinely exploitable in that specific environment.
In practice, that means narrowing millions of findings down to those that demand immediate action, and delivering remediation that fits the environment. With Astelia Agents, launched at Black Hat 2026, the platform carries a finding from triage through remediation to validation, orchestrated across the tools organizations already run.
About Astelia's Security Research Team:
A team of six: five researchers and one lead. The team combines people who ran defensive cyber operations, including work on Israel's National Red Team testing the state's critical infrastructure, with people who ran operations against target networks to extract intelligence from closed environments. That mix produces a very specific kind of expertise: an intuition for how real networks are actually built, segmented, and defended, and where the assumptions in that architecture quietly stop holding. Modelling an enterprise network accurately is precisely the hard problem at the center of our product.
What makes it unusual is the mandate: this is not a research team that publishes and hands off. The same five people own the deepest capabilities in the product itself. They research a network component and then build the logic that models it, which means research and engineering are the same job here. Members of the research team personally lead technical proof-of-value engagements with customers.
What is your background in cyber, and what led you to specialize in security research?
I first discovered cybersecurity during my military service. I served for six years in the IDF, first in the cyber defense academy and later as part of the National Red Team at Matzov. I had two very different roles there. In the first, I was part of the operational team conducting real cyber operations against some of Israel's most critical systems. The goal was to compromise the network, find the paths that should not exist, and test the defenders’ response.
Later, I moved to the penetration testing team. In penetration testing, we would spend weeks or months deeply investigating complex environments, working alongside the people who built them, trying to understand the system from every angle, not to breach it, but to help the owners discover where they are exposed.
Over those years, my team and I saw almost every type of network: some of the largest and most complex environments in Israel, isolated networks, industrial systems, cloud environments, and everything in between. That experience gave us an intuition that is difficult to develop from documentation alone: understanding not just how networks are supposed to work, but how they actually behave.
During my last year in the army, I had the opportunity to work closely with US Cyber Command as part of CyberDome, a joint US-Israeli exercise. I led the Red Team, working against dozens of American and Israeli defenders during a two-week exercise in the US.
When the war started, I returned for reserve duty in Unit 8200. Later, I joined Microsoft Defender for Cloud as a security researcher, where I deepened my cloud security knowledge. After a few years exploring different sides of the industry, I decided to go back to my roots and join Astelia.
Someone once criticized one of our pentest reports by saying: “We find a problem for every solution.” I actually consider it a compliment. That mindset has stayed with me ever since: keep looking for the things others assume are fine, and find the problems before attackers do.
What does your security research team look like in action?
We are five people. Everyone has a specialty, a strong opinion, and usually a different idea of how something actually works. The advantage of a team like this is that there is always someone smart to talk to, someone who can challenge your assumptions or help you solve a problem you have been stuck on.
Our research starts from real customer problems. When we encounter a device, an appliance, or a technology that appears across customer networks, we dive deep into it until we understand its behavior well enough to model it accurately.
The output of our research is not a white paper, a blog post, or a proof of concept that someone else eventually turns into a product. We are also the builders. We write the core logic that powers Astelia, the engine that processes the data, models the environment, simulates attack paths, and finds the exposures that actually matter.
Because of the complexity of the problem, nobody works in isolation. A vulnerability in one network component often only matters because of how another part of the environment was configured, a segmentation rule, a routing decision, or a security control that was assumed to block a path but did not. Reachability is a property of the entire environment.
We also use AI heavily as part of our daily workflow. We build agents with dedicated skills for the technologies we research, helping us explore faster and preserve knowledge as we go. Historically, when someone spent months building deep expertise around a protocol or appliance, much of that understanding stayed with them. Now we capture that knowledge while doing the research so it becomes something the whole team, and the product itself, can build on.
How does the research team influence your company at large?
The network research team owns the core capabilities of the platform, so their findings do not get translated into a roadmap item and scheduled for a future quarter. They become the product, often within the same cycle.
Concretely, our entire value proposition rests on the accuracy of the network model. If the model is wrong about whether an attacker can actually reach a given asset, the prioritization built on top of it is worthless, no matter how sophisticated the AI above it is. So every hour of research into how a particular firewall handles a rule, or how a specific appliance behaves under a given configuration, translates directly into whether a customer is looking at the right thirty vulnerabilities or the thirty wrong ones.
The loop runs in the other direction too. Because researchers lead technical engagements with the customers themselves, they see the gap between what we model and what exists in the field firsthand, and bring it straight back into the work.
What has been your team’s most significant security discovery to date?
A moment that I strongly remember happened on a Thursday evening, as the best discoveries often do. I had just finished building a new capability that improved our ability to identify internet-exposed systems.
I deployed the feature and immediately saw something unexpected: dozens of interfaces that appeared to be exposed to the internet. The interesting part was not just finding the exposure, but understanding its impact. By combining it with our knowledge of the customer's network, we realized that one of these components was connected to a critical server segment, creating a potential path toward sensitive assets.
I tested the interface myself and was able to reach it, and we immediately shared these findings with the customer. At the same time, I showed the interface to another researcher on the team, who quickly discovered an application-level vulnerability in the web interface. An attacker could bypass authentication under certain conditions and gain access through the exposed interface.
A scanner can tell you that something is exposed. A vulnerability database can tell you that something is vulnerable. But understanding whether that exposure actually creates a meaningful risk requires understanding the entire environment, the network, the controls, and the path an attacker could take.
Who or what is your 'Moby Dick'?
For years, the industry has treated vulnerabilities as an asset-level problem: find a CVE, assign a severity score, and prioritize from there. But a vulnerability does not exist in isolation. The real question is whether an attacker can actually reach it, what controls stand in the way, and what happens if they succeed.
The network is the missing context. Over the last decade, the industry moved its attention to cloud, identity, and AI. The assumption was that the traditional enterprise network would disappear. But years later, organisations are still running massive, complex networks filled with firewalls, load balancers, routers, and decades of accumulated decisions. That is where many of the real attack paths still exist.
My Moby Dick is the moment when the industry will finally understand that a vulnerability does not exist on a server alone. It exists inside a network, behind controls, and along a path an attacker may or may not be able to take.
How would you characterize the competition between research teams today?
From my personal experience, the relationship is less about competition and more about different teams approaching the same hard problems from different angles. I have friends in many places who are researching similar areas, and we often exchange ideas, discuss challenges, and learn from each other. When another team gains recognition I see it less as losing a race and more as validation that the problem is important and worth solving.
Our own position is slightly outside that race, by design. We are not competing to be first to a named CVE. Our research is measured by whether it makes a customer's network model more accurate. For me, the most exciting part is seeing research turn into a capability that helps customers. When you publish a research article, it can be difficult to know the real-world impact it had. When research becomes part of the product, you get direct feedback: you see it detect new attack paths, uncover hidden exposures, and help organizations reduce risk. That is the scoreboard that matters most to us.
What is your take on the future of the human security researcher?
Every researcher on my team operates at roughly ten times their previous output, because AI agents handle the parts of research that are laborious rather than intellectual: enumerating configurations, reading documentation, reproducing behavior across variations, and keeping notes current.
The more interesting shift is what AI has done to institutional memory. Knowledge transfer has always been the structural weakness of research teams. A researcher spends six months developing an intuition for a particular protocol, then moves on, and most of that understanding is simply lost. We now document everything as it is produced, with agents holding the standard. Knowledge stops being a property of individuals and becomes a property of the team.
What has not changed is judgment. Models are excellent at exploring a space and poor at knowing which part of the space is worth a week of a person's attention. Deciding that a particular network component deserves deep investigation is a human call, and it comes from having actually operated inside networks like these.
The asymmetry worth worrying about is that attackers face none of the constraints we do. They are already running operations where AI sets objectives and executes end-to-end with minimal human involvement, and they do not need to be careful. Defenders do. That gap is real, and it is the reason the human researcher is not going anywhere. The job is just changing shape: less time spent doing the work, more time spent deciding what work is worth doing and verifying that the machine got it right.
