Reblazing Web Security, Announcing a New Product, and Listening to Records with Tzury Bar Yochay from Reblaze
Reading time: 15 minutes
Web applications contain sensitive data like user information, financial data, and intellectual property. That data is valuable and alluring to malicious attackers. Cyber attackers looking for vulnerabilities and weak spots to gain unauthorized access for stealing data keep web applications under constant threat.
Web applications have had security issues since their beginning. The deployment of new protocols and technologies circumvented many of them, but an alarming number of applications are still unprotected from an even more alarming number of vulnerabilities.
Protecting web applications and traffic is imperative in the current threat landscape. A solution that encompasses different approaches is crucial in web application security. Tzury Bar Yochay recognized the issues that come with existing web application security solutions and set out to create a single-tenant cloud-based platform that provides next-gen WAF, DDoS protection, bot management, and API security.
Reblaze started 10 years ago in Tel Aviv, Israel, and now has offices in the US and Singapore. While working with bigger companies, they continue to bring innovation to the web security field. We met with Tzury (while social distancing) to learn more about the vision behind Reblaze and how they were able to "Reblaze" web security. We even got to be the first to hear about an exciting new project - Curiefense and got a glimpse into Tzury's impressive record collection.
SecurityTrails: Hi Tzury! Tell our readers a little bit about yourself and your background. (We here at ST already know, since you have been here from the start, as far back as one of the early ST meetups in LA!)
Tzury Bar Yochay: Right on, that was the Manhattan Beach take on Silicon Valley. An AirBnB apartment where the ST team gathered to work on the product in its early days.
I started Reblaze after several intensive years as a cybersecurity consultant in the intelligence community, working for three-letter agencies. Back then, setting up a WAF was a complex process, installing an appliance within the datacenter. Maintaining it was an even more complex task.
For DDoS protection you needed a different vendor, and the solution was either an appliance or a scrubbing center. Unfortunately, even the best solutions weren't providing full protection against attackers. For example, DDoS solutions tended to perform poorly on layer 7 (HTTP), and true human/bot detection did not exist. My idea was to set up a PaaS platform that would provide all those capabilities on top of a reverse proxy, while leveraging cloud capabilities just emerging at that time.
We looked around and found there were only two companies with a similar concept, CloudFlare and Incapsula. However, we compared them to our prototype design and saw they had three key deficiencies — they deployed their own stacks on data centers, their systems were multi-tenant on both ends (runtime and management console), and they had only rudimentary bot-detection capabilities. Conversely, our system deploys on public clouds (for example, AWS), is single-tenant (each customer gets a dedicated Virtual Private Cloud), and at the time, seemed to be the only one that could detect headless browsers and analyze user-generated events, such as mouse movements, keyboard strokes, and touch-screen taps.
Even though there was competition, we knew we could do better, and we created the Reblaze platform.
While bootstrapping sounds like a risky thing to do for many companies just starting out (and it is), most companies we know bootstrapped at some point. Reblaze did as well. What have you learned and what were the key takeaways from the experience?
Tzury: I can't speak for others, but for us it was the organic path to walk. We saw a problem, a growing problem, that we wanted to solve, so we dedicated ourselves to solving it. Once we had an MVP, we wanted to test it and get immediate real-world feedback. We found the new paying customers loved it, and we were fully committed to them and the product roadmap. So we were (and still are) busy with those tasks, rather than setting up and executing a roadshow for investors. It is indisputable that the best money you can bring to a business is sales money.
Reblaze is based in Israel, but also has offices and operates in the US. How would you describe the differences between the two countries, and their approach to cybersecurity, and the industry as a whole?
Tzury: Great question! Israel is a very small country. In order to succeed there, you must be capable of operating in a small place. The US is the opposite. Before operating country-wide, you must build a scalable platform.
Given that, starting out small in Israel and then "Americanizing" the company for scale seems to be the optimal path for a startup. It helps that the cultures are very similar. The US is the motherland of entrepreneurship, and respects problem-solvers and those who get things done on time. That is also the essence of the Israeli spirit, and this is one of the reasons Israeli companies do well in the US.
How would you describe a "Reblazed" website?
Tzury: Most people are familiar with airport security so I'll use it as an analogy for securing a web application. Traditional web security is like an airport in the United States. Passengers come in, they go through a quick assessment by the TSA, and then they're allowed onto the plane.
Reblaze's multilayered approach is similar to an airport in Israel, where security starts several miles before someone enters the airport, continues through the airport itself (including thorough profiling of each passenger), and extends to the in-flight security personnel on the aircraft among the other passengers.
In Reblaze, we have the security components at the network edges, profiling, blocking, and monitoring incoming traffic. After that, Deep Packet Inspection (DPI) looks into the packet content (kind of like human and luggage scanning), and then the in-app sensors are monitoring and analyzing human presence and interactions, and device state. A Reblazed platform is one that's empowered by a high-intelligence profiling, monitoring, and controlling system. Did I mention that our Ben Gurion airport is considered the most secure civilian airport in the world?
For some time, organizations have moved forward from traditional services to APIs. What has this transition to rapid innovation of APIs done to the current attack surface?
Tzury: Yes, a microservice architecture is becoming the go-to choice. This means a large application is split into smaller pieces that operate independently of each other, communicating via APIs. Therefore, a session is conducted across multiple parallel services. Since they're all exposed to the public web, the attack surface area is larger in size and risk.
Our goal is to provide a centralized point of management and enforcement, while adjusting policies for various APIs according to their roles. For example, an API used by a web application will run under a different policy than one used in both web and mobile.
How does the traditional approach to web security differ from API security?
Tzury: If properly built, an API can make some aspects of security easier, even though APIs, in general, often make other aspects more challenging. For example, if an API has a well-defined schema, the security solution can easily enforce that schema. For a given URL, the solution can allow the inputs the schema says are acceptable, while blocking all the rest. This dramatically reduces the likelihood of errors such as false positive alarms. At the same time, if an API is designated to be used outside of the mobile or web application, this can be more challenging, because by definition, bots are allowed. Here, the security solution has to distinguish the good from the bad and draw a virtual line between use and abuse.
Reblaze does this by modeling API activity on a session-level, as well as on the individual request level and detecting the outliers. We also have in-app sensors for APIs that are bundled with applications, which assist us during the session profiling process.
What is unique in Reblaze's approach to API security in order to fill the gaps that other solutions have left?
Tzury: Many other solutions have problems with APIs because they are based on traditional approaches to security. A solution meant to be "a WAF in the cloud" will still have many of the same shortcomings that a traditional WAF has. For example, if your primary means of filtering bots is to verify each client is using a web browser, then you'll have no way to filter out bots from API traffic, because there is no browser to verify.
Reblaze takes a different approach. We've been cloud-native from the beginning, so we were never constrained to a traditional approach. We were able to anticipate and prepare for a number of trends, even before they became significant on the web. Reblaze treats an API as just another channel of traffic, so our multivariate approach can detect and block threats regardless of whether the requests are coming into a site, API, or mobile application server.
Reblaze offers a next-gen WAF, or better called a WAAP which deploys on public clouds and reduces compliance and risks from multi-tenancy. Tell us a little bit about your "crown jewel."
Tzury: Multi-tenancy (sharing a platform with other users) is a dirty secret in the cybersecurity industry. Reblaze does not offer it. In fact, we refuse to do so, but most of our competitors require it.
Here are three real-life examples of how it creates security risks. First, when you share a security platform with other users, you can be affected when one of them gets attacked. One of Reblaze's larger customers first came to us after experiencing this. Their security platform (provided by a large, well-known company) went down as a result of an attack on someone else, and they were left unprotected.
Second, there was an infamous incident where organizations got penetrated and hacked by another user through their shared management console. I can't reveal the security provider's name, but you would recognize it.
Third, sharing a platform means your private data can inadvertently get revealed through software bugs. The "Cloudbleed" incident is a prominent example of this. A certain large provider was caught serving (to the public internet) web pages that contained private data from its users, and this went on for months before it was discovered and fixed.
This is why Reblaze is a single-tenant solution. Each customer gets a unique Virtual Private Cloud, a dedicated stack for their use alone. It has the user experience of SaaS, but runs on your own cloud.
Single-tenancy is one example of many where Reblaze is different from our competitors. We take a "no compromise" approach to web security. On today's web, partial protection is the same as no protection.
As we mentioned, your WAF deploys on public clouds. What is the good, the bad and the ugly of public clouds and migrating to them?
Tzury: All of the Big Three public cloud providers have raised the bar in security, automation, and scalability. Organizations can deploy their infrastructure with confidence, knowing their chosen cloud is compliant with the standards and certifications, that data is encrypted at rest, and there's a full audit trail for any aspect of activity.
In addition, cloud vendors have expanded their offerings far beyond compute, storage and networking. They offer large sets of managed/hosted platforms such as databases, AI, developer tools, media services. One can build an entire operational SaaS fully on managed services, aka serverless. Pretty sweet! This introduces an inarguable level of comfort and a "submit-and-forget" mindset.
However, it comes at a price, both financially and technologically. One potential problem can occur when a corporation's culture gravitates in this direction, and starts making its choices in terms of managed cloud services. A few years later, you find that the SRE team now lacks the know-how for huge chunks of their infrastructure, simply because they haven't been taking care of those operations. And a worse problem is the vendor lock-in.
In OWASP Top 10 style, what are the most common web application security threats you have encountered with your Reblaze customers?
Tzury: For the last three years or so (2018-2020), it's easier to divide them into the top four categories, and then the rest.
At the top, with a frequency and intensity that surpasses all the others, are the various forms of bot attacks. These range from account takeovers, to dictionary-based / brute-force credential stuffing, and related attacks such as credit and gift card fraud.
Second, there's shell injection in all its forms. Whether it's a sequence of commands, or an often vulnerable, or sometimes even malicious, Wordpress plug-in that is leveraged to gain a remote shell directly on the server.
Third are application-level code injection attacks such as XSS and SQLI.
Another form of bot attack that is inevitable is a web reconnaissance attack. As soon as you expose a TCP listener on port 80 or 443, you will get it within minutes.
Other attacks are less common than these, although they still happen from time to time.
When a victim has suffered a DDoS attack, what are the first things you look at during the initial assessment?
Tzury: When someone (who's not a Reblaze customer) contacts us for help with a DDoS, the first step is to route their traffic through our platform. This can be done in a matter of minutes. Once their traffic is going through our system, they can handle the attack just like our customers do: Reblaze recognizes and blocks DDoS automatically. If additional intervention is necessary, the platform shows the origin, nature, and disposition of all incoming traffic, so you can see exactly what's going on and fine-tune the response.
How would you describe a successful DDoS mitigation strategy?
Tzury: Eyal (our co-founder and CEO) likes to use the analogy of a toll road checkpoint. There's an area where cars are stopped for payment, or snapped for auto-payment. In that area, it's common to increase the number of lanes and checkpoints, and keep the traffic streamlined.
DDoS mitigation requires those same two capabilities — automatic bandwidth expansion, and allocating compute power to keep inspecting and analyzing at scale. Because Reblaze runs in the cloud, we have both capabilities out of the box, so we stay on top of the filtering.
Of course, a crucial requirement is a security platform you can stream hundreds of millions of HTTP requests per second into and retrieve all sorts of metrics from the data, to analyze and detect the sources of the attack and update the security policies.
Keeping automated bots, spammers and scammers from their websites is the bane of existence for many. It is interesting that much of the bad traffic comes from hosting facilities and cloud service providers. How can we use ASN and its reputation to know the "bad" hosting companies and block bad traffic?
Tzury: ASN reputation is a useful way to quickly filter out bad traffic. There are blocks of IP addresses known to be controlled and used by bad actors, so requests coming from these addresses can be blocked. It's a powerful tool for cybersecurity, because it can eliminate large tranches of hostile traffic with minimal computational overhead.
I'm really excited about our partnership with SecurityTrails because the combination of our platforms makes each one richer. The data feeds and intelligence (that goes far beyond ASN data) from SecurityTrails is provided via APIs, so it can easily be integrated into other platforms such as ours. Reblaze uses data feeds from SecurityTrails to get intelligence on a scale (for hundreds of millions of domains!) that we couldn't get ourselves. Then, intelligence that Reblaze gathers and discovers about emerging and existing threats, seen within the billions of HTTP requests that we process each day, is fed back into SecurityTrails. So there's a real synergy here, where we are enriching and improving the quality and scope of both of our platforms' data.
What can we expect from Reblaze in the future?
Tzury: In just the last few years, we've entered a world where software, DevOps, and SRE engineers deploy massive and complex platforms, consisting of dozens of microservices, hybrid and cloud combined in declarative programming. This is the world of Kubernetes, Istio and the amazing innovation storm that is taking over the world of software.
Now imagine that within this world, you are in complete control of incoming traffic. You've established granular security rules and policies, along with a proactive security mechanism — an active, adaptive intelligence plugged into the sidecar proxy.
This fully automated system natively integrates with the toolchain you already use and runs inside your perimeter, so you don't need to compromise on security or privacy. You don't need to share your private keys or expose your user data to any third party, whatsoever. And it's open source.
I'm announcing it today, here on SecurityTrails — Curiefense, a new project named after the famous scientist and one of the most influential women of history Marie Curie, will be released to honor her birthday, November 7th, 2020. We developed the first version of this system in an intensive meeting in the outskirts of Paris, a few hundred meters from a house where she had her famous laboratory.
We've chosen to release this system as open source because we want to make enterprise-grade security available to everyone, whether they can use cloud SaaS or not (because some organizations can't), and whether or not they are even our customers. Our vision is to make the web a safer place for everyone, and this is a big step in that direction.
Most CTOs that I know have secret hobbies to recharge their batteries. What do you do to relax or fill your creative tank?
Tzury: My magic moments during the weekend are either watching classic movies, or listening to records. I have a modest and slowly growing collection of music that ranges across many genres and eras.
When I started, about 18 years ago, it was mainly progressive and psychedelic rock. In recent years, it is mainly jazz and blues. The older, the better.
The whole process of reading about the music's history, searching for, and finding the album adds "flavors" to the sound itself. As does the ritual of sitting and listening to a record being played. To me, it's like what "dry aging" adds to beef, if I may use that analogy.
I am not a collector though (someone who buys a record more for its market value). I match them to my heart and soul. Listening to a 78 RPM of Bessie Smith makes me tremble every time, even though it's been almost an entire century since it was released.
However, sometimes I get caught up in a gimmick. For instance, when I see a record that has acronyms like API, DoS, or WAAP, I must have those records, regardless of whether I like the music or not.
Final words
We hope you’ve enjoyed our newest interview with Reblaze founder Tzury Bar Yochay and enriched your knowledge on next-gen WAFs, API security, DDoS protection and even found some records you should listen to in your free time. Make sure to follow Tzury and Reblaze to stay tuned for the release of Curiefense and be in the know about their future projects that are set to make the Internet a safer place for everyone.
