In a recent article published by Security Boulevard, we talked about OWASP Top 10 Risk classification and overlap. In this post, we will examine tools that allegedly help address these risks. You may be at more risk than you’ve been lead to believe.
The following is an OWASP Risk Overlap diagram (based on the Security Boulevard article) will be used to illustrate different threat intelligence and detection mechanisms.
The following color-coded visual aids help understand what is possible to cover with which protection mechanisms. You will quickly see the enormous security misconfiguration and the danger it poses.
Virtual Patches
The square below shows what is possible to cover by signatures for vulnerabilities, also known as virtual patches.
All of them are based on well-known payloads and exploitation techniques. That makes it possible to deliver nearly 100% coverage by applying these kinds of signatures.
The corner case here is a window between when a vulnerability shows up to when the corresponding signature can be generated. Current industry time is roughly between 20 to 200 hours from the first exploit detection to virtual patch signature delivery.
Problems with Patches: Adding attack-specific signatures
Now, let’s add to that all the detection possibilities of attack-specific signatures, like SQL-injections, XSS (cross-site scripting), and other things covered by CoreRuleSet (CRS) or libinjection and color them bright yellow.
These yellow bubbles are not so wide, are they? That’s because they cover only input validation-based attacks where it is possible to apply signatures on data inside incoming requests. And this is why virtual patches frequently fail to detect A2, A5, and A10 OWASP risks by these methods if the vulnerability in a particular application was not detected before (A9 Known Issues).
The HUGE problem: An ongoing classification problem
Obviously, there is a big security misconfiguration in A1 Injection detection by signatures to attack types. This is because OWASP added all the injections into just one class. In truth, injection attacks are very different.
The current classification system groups all the syntaxes into a single class. That creates a huge problem. Arguably, you could call an XSS an HTML/JS Injection and include it into the same risk classification. For now, we decided to do not do that. All your external data sources from filesystems/OS to databases use custom protocols where the injections attacks are possible. Cassandra, Redis, Memcache, Riak, and all the other data sources are at risk with potentially injectable protocols and the need to detect targeted attacks.
Since it’s impossible for protection vendors to follow 100% of the technology stack used by their customers, we predict that this security risk will continue until this is fixed.
