You know that cybersecurity is important to the health of your organization, but are you doing all you can to ensure your systems are safe and sound? Maybe you use virus and malware protection, conduct regular cybersecurity assessments, require multi-factor authentication (MFA), and train your staff to handle social engineering attacks. But did you know that none of these security measures directly protect your website and any data accessible through your website?
Just like you should make sure your network is protected from cybersecurity threats, you need to make sure your website is protected as well. If your website has e-commerce functionality or handles valuable information such as membership and accreditation data, then you need to make sure you have measures in place to protect it.
While most people have heard of traditional firewalls, not everyone has heard of web application firewalls (WAFs), which are a specific kind of firewall that protect websites against unique threats unmitigated by traditional firewalls. Since all associations have websites, and since traditional firewalls don’t protect websites, DelCor encourages all clients to consider implementing WAFs as part of their security measures.
Traditional Firewalls vs. Web application Firewalls (WAFS)
Traditional firewalls act as barriers between your network and the rest of the internet or between your personal device and any outside activity. Whether they protect your network or your personal device, traditional firewalls protect your data by monitoring traffic, detecting potential threats or unusual activity, restricting access, and alerting users.
For example, when you try to open files from networks external to your own, your firewall may flag those files and alert you. In such a case, the firewall has performed its function of serving as a barrier between your network and outside networks.
What’s important for distinguishing traditional firewalls from WAFs is not how they work but rather where they work. While traditional firewalls filter traffic according to IP addresses or port numbers, WAFs filter out traffic at the application level, catching things traditional firewalls wouldn’t catch. In other words, WAFs filter the content of the traffic at the application level, whereas traditional firewalls block out traffic because of where it’s coming from.
A WAF protects web-based applications by monitoring traffic between web applications and the internet. Broadly speaking, what this means is that WAFs perform a similar function to traditional firewalls from the perspective of an end-user.
How WaFs Work
Security experts configure WAFs according to rulesets, which define how traffic on your website gets filtered and handled by the WAF. These rules work in unison to filter the interaction between different web applications much like a French press filters out coffee grounds while allowing coffee to pass through the mesh.
The particular settings and combinations of rulesets governing a WAF’s function are called configurations, and what configurations are chosen for your organization’s website depend on a variety of factors including what kinds of web applications you use, what functions your website performs, and what the current insecurities in web applications may be.
Web application insecurities can change over time depending on how applications are coded, what kinds of insecurities have been found, and what those nifty evildoers might be up to at any given time, so updating your WAFs configurations is crucial to their effectiveness.
To help the general health of our online communities, the Open Web Application Security Project (OWASP) publishes a new list of the top 10 greatest threats to web applications every year. This list is designed to promote the general health of cybersecurity practices around web development and web management. While some ruleset options are proprietary to the platform, all platforms will include the current recommendations made by the OWASP.
wHy WaFs Are a Necessity
Web applications will always have vulnerabilities that can be exploited, and as developers update code and produce greater functionality, there will continually be vulnerabilities that we are initially unaware of. Late this past year, a web application vulnerability threatened nearly a third of all web servers worldwide. The vulnerability, log4j, is code written in Java that’s used by a wide variety of platforms because of its versatility and accessibility.
Developers use log4j as a record of activity, allowing them to track data, troubleshoot problems, and refer to previous versions of their work. What this means is that log4j can be used to track a lot of data across many different domains. Hackers exploiting the log4j vulnerability can likewise use this fact to access, steal, corrupt, or otherwise tamper with data tracked using log4j
To their credit, the developers of log4j quickly released a patch responding to the vulnerabilities, and developers all over the world worked quickly to secure websites from potential attacks. But patching web applications takes time and only works to mitigate known vulnerabilities. WAFs work to mitigate threats and minimize the damage done while developers patch for threats such as log4j.
What does this example teach us? Well, it reminds us about the inherent dangers present in web applications and anything else that connects to the internet. In order to secure web applications from general threats that developers aren’t actively working to patch, we need to use WAFs. Patching an application, much like going to the emergency room, is sometimes necessary, but it’s good to lessen trips to the hospital by following safe habits like wearing a helmet while riding a bike.
That is why DelCor recommends that all of our clients use WAFs to protect their websites. Clients protected by a WAF were less vulnerable to dangers posed by log4j and were able to keep their data secure until patches were developed.