I have had a chance to pose a few questions to Alexander Golovko, one of the co-founders of Wallarm and our CTO. Here are Alex’s reflections on Wallarm and some technology trends.
How did Wallarm get its start?
Ivan (Wallarm’s founder) has involved me in various projects on and off since 2010. By 2013 we have arrived at an understanding that this space is ripe for a new product, which thinks like hackers and closes gaps left by the then-current technology stack. The first thing we did just provided enhanced log analytics to a web server. Once we got that to the real customers and got our first POCs going it became obvious that it’s not nearly enough. We got our first investment and embarked on developing our first real-time application protection product. Five years later we are still here and protecting hundreds of customers from malicious attacks.
Can you tell us a story about a scary encounter with the real life / customer experience and how you worked around it?
Well, clients are clients. They are always right and you just live with it. I guess one example from our early life is when an online store owner started complaining about unreasonably heavy traffic from Wallarm scanner. Turned out, his online store was crashing and the “huge” load of eight requests per minute. I guess his normal load was one purchase an hour… Hard to predict something like that. We had to turn the active re-checker off for him.
What are your thoughts on Open Source?
It’s a great approach that allows people on different continents to cooperate and, together, get to the goal faster. It’s definitely helped us here to get to a working product faster, if only for the use of the open sources OSs.
I encourage everyone on the team to contribute more to open-source. Last year, we released libdetection, signature-free library to detect injection and commanding attacks. It’s funny that 90% products on the market still use RegExp/Static signature. Libdetection is a fully working PoC that can analyze an arbitrary string and detect a well-formed request, like a SQL statement, identify potentially dangerous payloads, like RCE or injections in the data and so on, using nothing more than grammar analysis with syntax definitions.
Throughout my career, I’ve been involved in several open source projects. Probably one project worth noting is a system for reserved copying I maintained for Debian for a while. Unfortunately, not as much time for that lately. Got my hands full with Wallarm.
What are the key elements of the Wallarm technology stack? Why did the team choose these technologies?
The key principle of our design is separation of real-time and non-real time data processing and the selection of tools that are appropriate for each.
The need for fast real-time response when a request is coming in is why we have decided on the hybrid architecture in the first place. Wallarm Node which is installed locally and is mostly written in C can process the requests in-line as they are coming in, adding very little latency. If it does need to do real-time processing, like behavior analytics, we use Golang and Tarantool depending on the task.
The logic for this fast processing comes from our machine learning engine, which is, of course, a critical piece of our IP. The hard part is that it’s pretty much in every part of the stack, from parsing protocols, to vulnerability detection, to testing. Figuring out the neural network architecture, calculating parameters and so on is a fairly heavy computationally and may take some serious off-line processing. We use Riak and ElasticSearch for data processing there.
The interesting bit there is that the algorithms around ML/AI have been evolving as the company matures. We might have started with the simpler ML earlier on, but by now we have fairly advanced neural networks, that have different architectures for different tasks. For parsing we use n-grams and other language processing algorithms, for detection, it’s closer to classic convolutional neural networks, for sharing intelligence between detection and scanning its reinforcement learning.
Looking at the more recent trends, over the last year or so we’ve been heavily involved in migrating our cloud side to microservices and Kubernetes. Defining every service as a separate module with clear APIs is a very good fit for us, both architecturally and for our own operations, since SaaS is where we deliver the most value and we need to be very agile in deploying and maintaining our services.
We have always employed API-first approach with an eye for having Wallarm being integrated into automation systems and existing DevOps processes. All the data we have are accessible via APIs that are available to customers and partners, defined by Swagger and generally what you’d expect from the API best practices.
How we decide on using NGINX as our enforcement platform?
We have initially selected NGINX as the enforcement platform on the Wallarm Node to take advantage of the performance and get natively integrated with something that is already a primary choice for most our clients. Obviously it was the right choice as became clear once NGINX introduced the support for dynamic modules, meaning there is no need for a separate image/compilation of the module for each one of NGINX. It’s much easier to support a variety of field versions with the dynamic modules.
Our architecture is inherently modular. The actual code is, obviously, separated into a distinct library and supports standard interfaces. The idea there is to stay mobile and be able to eventually support other load balancers and web servers as enforcement platforms beyond NGINX.
If you were to offer security advice to the SaaS practitioners, like CISOs, to keep their apps and infrastructure secure, what would be your top 3 things?
Firstly, make sure that you have tools and processes that are clear, documented, and followed by everybody on the team. Chaos breeds chaos. Secondly, use best of breed tools, like Wallarm, that can help take care of your needs professionally. Lastly, focus on what works. There are lot of fashionable tools, and a big temptation to try and focus on the thing you hear most about. I think it’s important to be pragmatic and trust your team to know what is good enough.
As a leader of the team, what do you find most challenging?
Now, when we have more than 40 people across the globe we face new challenges in the way how we plan, sync up, interview new hires, etc. The key thing I am working on is changing the direction of expertise and creativity flow: moving from the ranks up as well as from the top down. Also, working on optimizing the work environment and getting the guys to be more productive.
What will Wallarm be when it grows up?
We want to be a complete 360 security solution used by the development team, QA team, operations, security researchers, auditors, everybody. And we can do it! We have great expertise in security audit, pen testing, developing defenses… It’s just a matter of eating this pie one slice at a time.
Thinking about your network and talking to other CTOs, how does what we do compares to the industry best practices?
The industry moves very fast. What’s cutting edge today will become mainstream in 3–5 years. The key is changing the perception of the market — getting people to think and reflect on the opportunities of the world around them.