When we first starting a conversation with our prospects, we are frequently asked,
> “Just how will I know that Wallarm is working?”
To help answer that, let’s take a look at the report we sent to one of our customers last week to understand what kind of threats Wallarm defends agains.
Wallarm customers get this kind of detailed report weekly — just to keep track of the state of affairs. In addition, they get ad-hoc alerts and bugs filed right into their bug management system if there is a critical security incident.
First thing one will see in the report is the summary. Here we see the overall state of the application security. In this case, the state of risk level is fairly high, and it would be a good idea to pay attention to the rest of the report to understand what is going on to drive the risk up.
First things that are being reported are the attacks. Attacks are attempts by hackers, automatic bots and other malicious actors to penetrate and exploit the application. Most of these attempts will not be successful, partially because the application may already be patched to address these problems, partially, because the attacks are blocked by Wallarm WAF.
However, it is helpful to know if your application is _specifically _under attack, or what you are just a subject of the aggressive internet environment. A good indication here is “Cost of attacks” field. Essentially, it shows you, approximately, what was the cost of the resources engaged into the malicious attempts during this period.
The common types of malicious attempts against users. XSS or cross-site scripting is the most common attempt in this category. The second type is attempts against servers, such as Remote Code Execution (RCE) and (SSRF) Server Side Request Forgery.
Lastly, there are attempts to compromise backend data system. The most common attacks of this type are SQL injections, although non-SQL databases may be vulnerable to similar style attacks.
Once you’ve looked at the attacks, next come the vulnerabilities.
Vulnerabilities are bugs & holes in your application, that if not mitigated, and allow the attackers to gain control of the application.
First thing you will see is the summary of all vulnerabilities at the beginning and at the end of the reporting period. Of a particular importance are vulnerabilities marked with © for Critical.
In this case we see a critical vulnerability in the php script implementation retrieving data from the SQL database. The details of the vulnerabilities are explained first.
Following that we see the description of where the vulnerability was discovered as well as an example of an exploit that could take advantage of this vulnerability if it was discovered by an attacker.
Last thing the report shows are security incidents. Any security incidents that show up in this section mean that some of the aggressive attempts that have been reported in the vulnerability section are trying to exploit observed and confirmed application vulnerabilities.
Applications protected by Wallarm will get virtual patching, even if the security incidents are found. However, any time you see a security incident it should be an immediate call to action to apply the patch, modify the application or mitigate this real risk in some other way. If security incidents are discovered, an immediate alert is also sent to responsible individuals, both via email and via integration with bug systems.
Try Wallarm protection on your own application with free 14 days trial.