6 places to look into when auditing or assessing risks in and around Web Application Firewall (WAF)

Web Application Firewall (WAF) has become a security imperative whenever a web application goes live. Absence of a WAF in an enterprise is sure to get raised as a risk or an audit finding. However, many auditors and risk assessors miss some or all of the below 6 important areas related to WAF.

So here are 6 focus areas that the risk assessors and auditors need to be mindful of, while auditing or assessing risks, in and around WAF.

Not all public and critical applications are protected by WAF

Coverage is an important attribute of a security control, and an oft-ignored one. You should check whether,

1. There exists a master list of applications, with defined process to add/remove/modify entries to that master list? Which means you need to check,
   1. if there is a master list of applications available with some function/department (usually IT),
   2. If that master list is properly controlled (i.e., any updates, additions, removals, etc. need to be reviewed and approved before they happen, periodic review of that list is in place, etc.), and
   3. If criticality/sensitivity of information in an application is pointed out via a controlled, internal process.
2. All public facing and critical applications are protected by WAF?
   1. Usually, you will need to configure WAF for each port that is used by application. So, if an application uses 4 ports (e.g., 9001, 8443, 443, and 80), the WAF administrator need to configure WAF for each port, as part of policy. Be sure to check for that.

Managing Sensitive information that passes through WAF

This is a potential landmine for all those applications that inspect SSL traffic (also called 'SSL Inspection'). All sorts of sensitive information (e.g., credentials, access tokens, transaction payloads, etc.) are available in plain-text, once that layer of SSL is removed.

While all WAF players provide mechanisms to hide/mask that info, one needs to configure it, for each application and sensitive area (within that application). It is a tedious job, that lazy vendors and administrators tend to skip on, unless explicitly asked. You need to check that.

Always learning, no plans to block

When deployed, WAFs are always in learning mode. They inspect traffic, analyze it, and flag any unusual behaviour for manual inspection. Once a human inspects and flags it, WAF knows how to handle that pattern. This goes on for a while, till humans decide that WAF is ready for action.

Then they put it on block mode. No more flagging and inspection after that. WAF takes action as commanded (block, usually).

Issue is - sometimes the learning mode is never stopped. So what? You'd ask.

You can bet that not all requests for manual inspection will be looked at, beyond a point (imagine a business critical application that gets lots of hits. Ergo, lots of requests for manual inspection. Do you think a human will look into all that requests with the attention that it needs, all the time?).

Improper log monitoring, backup

1. No integration with SIEM (Security Incident and Event Management) - We have a dedicated administrator who looks at WAF console, day in and day out. What do we need SIEM for? Issue is - WAF is handled by first line (IT), whereas SIEM is 2nd line (InfoSec). As a rule of thumb, your SIEM should catch all pertinent issues highlighted by your first line tools. Not integrating WAF with your SIEM is a recipe for disaster.
2. Insufficient integration with SIEM
   1. Only WAF alerts go to SIEM, but not the GET, POST requests. So you have nothing to check the false positives against (especially if the alert is more than 2 days' old - see last point). You say your SOC completes all alerts in the same day? Liar, liar…
   2. Do you get alert on SIEM if someone removes an application or a profile from WAF, or makes changes to the settings? You say your WAF is handled in-house and all staff signs NDA/SLA. Liar, liar…
3. Insufficient backup (of traffic) - What? You store only 2 days' worth of traffic on WAF appliance? Oh, so you never changed that default because no one asked you to? What if we want to investigate something that happened a week ago? Thanks, I will need that "all the best".

No HA (High Availability) or plans for one

Even if you project the WAF in DR (Disaster Recovery) site as HA, it is Ok. No organization can have all security controls with redundancy. You make with what you have, so long as the intention is right. However, HA means,

1. Settings (policies, profiles, etc.) must sync between the appliances that are connected in HA mode. You need to check whether that actually happens (hint: it doesn't always sync in real-time).
2. There is a configuration somewhere that says - route traffic through WAF2 if I (WAF1) breaks and vice-versa. Look for proof of that configuration. Also, check if it manual or automatic. If manual, whether that manual switch-over is tested as part of BCP/DR drill. No drill, no dice.
3. As I mentioned above, if HA is not present, there should be some compensating controls to ensure that if WAF goes down, security doesn't suffer while business continues (ISO 27001 enthusiasts will note the control 5.29, Information security during disruption). An example of compensating control set (of not having WAF in HA mode) could be: -
   1. Backups (of WAF config, policies, etc.) stored at all layers (somewhere within network, somewhere outside network but within company, somewhere outside of company), on a daily basis. The backup is automated, doesn't need human intervention. We get alerted if any backup fails.
   2. We have a contract with the WAF OEM/vendor who, during disaster, provides us manpower and makes another instance available within 5 hours (on cloud). The entire configuration import (from the old WAF) gets done in another 3-5 hours. We know because we have tested for this during our Drills and have reports to prove.
   3. All of that is documented in an SOP, with full time WAF administrator to handle disruptions due to un-availability of WAF.
   4. NOTE - The comprehensiveness of controls change depending on the risk (of WAF un-availability) that the organization perceives. Regulated entities (like a Bank) will have more sense of urgency than a non-regulated one. So, one has to assess risk in that light. Remember, lack of control is not risk.

No skilled resources or business continuity planned (if there is one) to manage WAF

A competent WAF administrator probably will flag most of the risky areas. But people who know their jobs, are extremely rare. Which means, planning for such a person's replacement/backup - takes a long time. Unless an organization plans for it (SOPs, supervisor focus, management focus on business continuity, etc.), it won't happen. Check for it.

‎You can also follow the Risky Context channel on WhatsApp (if WhatsApp is your thing. Your number is not shared with others when you connect to my channel): https://whatsapp.com/channel/0029VaDqrFU8aKvQohD5nq0r