Destiny and Defensive Application Security
In some cases you choose your own destiny and in other cases it’s chosen for you.
Since this is my first post, I will introduce myself. My first name is “Or” – an odd name for someone who works in web application security research. Actually “Or” is a Hebrew name meaning “light” (most Hebrew names have a meaning) so I guess my destiny could have been to work for the national electrical company or perhaps as a bulb salesman. :)
Actually, there’s a well-known joke that I particularly relate to – see below.
In my case you can replace “DROP table students” with “OR 1=1”
I’ve had a few annoying experiences of my own when trying to register with applications that rejected me because of my first name, saying it’s not valid. :(
This leads me to the issue that I wanted to talk about which is security rules writing.
While offensive security has the charm and the glory, defensive security often takes the blame if either you block the wrong users (for example, searching for SQL logical condition “or” in user input), or you miss attack detection and the application gets exploited. Writing the right security rules is not an easy job; because they should answer the following:
- Full application security detection coverage
- No false positives
- No false negatives
- No performance impact to the security device (that can lead to performance impact to the protected application)
Now the real magic is in finding the right way to balance between all these requirements.
BIG-IP Application Security Manager (ASM) was built and designed to resolve these challenges by having the following capabilities:
- Deep HTTP understanding – HTTP requests are parsed by ASM engines and each signature is searched on the relevant parts of the HTTP request. This functionality prevents false positives and allows granular security policy configuration.
- Automatic detection of false positives – Before enforcing signature blocking, ASM places in staging each signature or violation in the security policy, and make sure that it has no unexpected detection hit per HTTP object (e.g. – signature matching on a specific parameter on a specific URL) that may indicate possible false positives on that HTTP object.
Combining these functionalities allows ASM users to apply a complete security policy without loosing detection (false negatives) and without the burden of false detection (false positives) that may have some effect on the ASM performance.