Important note. Care about vulnerabilities. Not about attacks. Buy Burp license. Run appsec training for all of your developers; it's easy while you're small.
Disclaimer: I am a co-founder of Wallarm mentioned in preso.
The main idea about Wallarm is to get inner knowledge of how the application works and how users use it. Based on this data, we craft dynamic rules for every single applications or API.
The simplest example is what data transmitted in different parameters of the form field or API calls. For example, it's OK if someone put an SQL Injection payload at Stack-overflow site in the form writing a security-related article. It can be a normal behavior. Meanwhile, SQL injection payload is probably a malicious thing for a login form at your bank website.
We wouldn't ban request only if it is sent with curl. There is a set of different factors and statistics that are taken into the account. E.g. if you run this requests too quickly and it is sent with curl, it can be considered as a malicious activity.
Hackerone and Bugcrowd do a great job. And we recommmend to run bug-bounty programs all the time.
But companies which run fast and deploy code everyday with CI/CD (or several times a day) it's almost impossible not to introduce new vulnerabilities. This is where solutions for continuous security are incredibly helpful.
1. Customers analyze traffic with locally installed NGINX-based instances (there is not DNS take-over). They send applications/traffic statistics to Wallarm Cloud so we can run machine-learning stuff. We had a lot of work done for initial training of the system using our own experience in web app security (more than 250+ pentests for top-tier companies + a lot of researches done by our team like SSRF bible). We also use different honeypots and now statistics of customers with a high volume traffic.
2. There are some details about ML technique covered by Ivan for another comment
3. We have different tasks with SiftScience. SiftScience provides a fraud-detection. Wallarm protects web apps and APIs against data breaches. But these tasks are related for some of our customers.
It absolutely has. The vulnerability was detected with a vulnerability scanner built in Wallarm. As for detection of attacks, in many cases, it's much easier to identify the attacker when he runs several requests than to stop only one request with a ready-to-use 0day exploit. And what's even more important, you need help to fix vulnerability unless attacker discovers it and find the way to evade WAF
Pity you get it in this way. Exploit for WebSphere is just an example of a complicated case with Base64 inside XML where Wallarm can detect malicious request other WAF usually fails.
And, no one asked to pay anything until getting proper results while 30 days free pilot (it could be extended). Give it a try
Signal Sciences launched a bit after us. The main difference is in the result:
- Guys are helping to detect anomalies and attacks, and I believe they're doing this better than regular WAF does.
- Wallarm helps to discover exploitable security flaws and incidents (vulnerabilities exploitation) within attacks/anomalies which it detects.
There is still lack of technical details on Signal Sciences website. And no public demo. Hey, guys, give us a try :)
What we have already published to open-source is libdetection (https://github.com/wallarm/libdetection), a library implementing a completely new way to detect attacks. This approach allows us to implement attack detection without having to specify precedents of attacks. I mean it doesn't require attacks samples to learn at all. Instead, formal models are used.
And it is already one of the approaches Wallarm uses to detect malicious requests.
Regular WAF just detects attacks. Thousands of attacks. And what to do with this knowledge? In a case of a traditional security solution, it's never clear — if an attack is just scanning with no harm or someone already downloading database over SQL injection vulnerability. You need to analyze all your events manually
Wallarm does more. It discovers which of the attacks are in fact targeting vulnerabilities.
This became possible because of combination defensive and offensive techniques (NGWAF + vulnerability scanner in one core).
2. Attacks/anomalies detection driven by machine learning
It's all about statistics and understanding the structure of the application and its users' behavior. Wallarm Nodes send a lot of statistical (impersonate) data to Wallarm Cloud, so we can get a set of facts about application:
- here is the SOAP API;
- here is XML API;
- here are JPG uploads are allowed
- here is field of the form, with CC number (16 bytes, digits only)
There are general ruleset to detect attacks without learning at all. But when we have an understanding of inner knowledge of the application, we can apply this set of facts of application to the general ruleset and get dynamic ruleset for every application. Wallarm Nodes get dynamic ruleset every 15 minutes from the Wallarm cloud.
As a result, it makes possible to protect APIs and apps with frequent code deployments and not to worry about false positives (we saw this many time: in the case of traditional solutions security team is usually required to reconfigure rules after major application updates manually or semi-manually. Hours of useless work. An enormous obstacle for CI/CD. And here what we see all the time: no one wants to get this work done, so security solution works just in monitoring mode WITHOUT actual blocking of attacks).
3. Performance and scalability for DevOps
Signature-less filters are very fast (we have Badoo social network/dating site with 200+ million users running their performance test for their PHP-stack application and they don't see performance degradation). Everybody already knows how to deploy/monitor NGINX with favorite orchestration tools. Wallarm is just a module for NGINX. Now, with the support of dynamic module by NGINX you can even use your existing NGINX instances.
I argue that it is a complete black-box for the customer. What blackbox is full proprietary hardware boxes or virtual appliances with operation system inside from old-fashioned vendors like F5 (no offense) or iMperva (again, no offense). Or entirely cloud solutions which take all your traffic. In a case of Wallarm, you work with your Linux environment; you can see all the Wallarm scripts and content of an in-memory database. And we share the source codes of Wallarm Node with our customers. Yes, have not yet published them in open-source, though.
WebSphere takes payload in Base64 inside the XML. To parse everything (and do it fast), unfold the structure and detect the attacks is still almost impossible thing for most of the WAFs