<img height="1" width="1" style="display:none;" alt="" src="https://analytics.twitter.com/i/adsct?txn_id=nv7vl&amp;p_id=Twitter&amp;tw_sale_amount=0&amp;tw_order_quantity=0"> <img height="1" width="1" style="display:none;" alt="" src="//t.co/i/adsct?txn_id=nv7vl&amp;p_id=Twitter&amp;tw_sale_amount=0&amp;tw_order_quantity=0">

Why Signature Based Security is Only the First Step

Richard April on Feb 07, 2017

Think of the security infrastructure of your application as its doctor. When working properly, it diagnoses threats to your system and prescribes the right course of action to keep that threat from Why signature based security is only the first step to healthy applications.jpginfecting your application - much the way your doctor would diagnose your illness and prescribe you the proper medication.

Let’s say you go the doctor with cold symptoms: a cough, sore throat, and runny nose.
If your doctor simply assesses your external symptoms, and follows the checklist for what these symptoms indicate, she might conclude that you have a cold and prescribe a decongestant until the cold passes. However, what’s more likely is that your doctor will see your external symptoms and recognize that it might be a cold, but that it could also be several other things that present with similar symptoms. She would then run some tests to understand what is happening inside your body, which could indicate that it is strep throat, pneumonia, or something other than a cold. If she only looked at you and consulted the symptoms checklist, she may prescribe the wrong treatment. This same scenario can happen to your applications, allowing attacks on account information or vulnerable code to access your data.

Relying on a Web Application Firewall (WAF) to protect your applications is similar to your doctor relying on a checklist of known symptoms without running any internal tests. The WAF has no way to see what is happening inside the application. It can only assess requests at a superficial, perimeter level. A WAF then uses signatures to determine if the code in the request is threatening or legitimate. A signature is a database of pieces of code that are known to be threatening, and could compromise the security of your application. If the string of code matches a signature for threatening code it is blocked.

While this may seem effective, it raises a lot of issues. Because a WAF has no way of knowing what is happening within the application, only what it looks like from the outside, it churns out a lot of false positives. The string of code is removed from the greater context of the request, making it difficult to determine if the string is malicious intent, or an actual user. This has negative effects as it skews your security analytics, and can block a real user from accessing the application. Similarly, if your symptoms were a cough and a sore throat, but not a runny nose, it is still possible that you have a cold despite not matching all of the symptoms precisely. If the code is malicious but does not match the signature exactly, hackers often add extra encoding so attacks don’t match any signatures, it may not be diagnosed and blocked - once again giving it access to your app. Furthermore, if a malicious string of code comes through the application, and no signature exists for it, no security measures are taken as it does not recognize this code as threatening. Signature based WAFs, then, can only protect against known vulnerabilities, meaning if an unknown vulnerability is exploited, it will successfully breach the application.

The best approach you can take to protect your application from vulnerabilities is the same approach your doctor takes to protect you from illness i.e. a combination of external observations and internal tests. Using a symptoms checklist or code signature is ok as a first step, but for the best results you must understand the greater context of the threat from what is happening inside. This is where Runtime Application Self-Protection (RASP) excels. Unlike other web application security solutions, RASP is positioned inside the application itself. From this vantage, a RASP solution is able to learn what it looks like when your application is running the way it should. When it appears that something is off, RASP can asses the code based on the full context of how the app is supposed to work to determine if it is at risk. This produces a higher success rate and fewer false positives, and will not inconvenience legitimate users. To learn more about how RASP works and differs from WAFs, read the Real-Time Web Application Security whitepaper.

Download the RASP Whitepaper