- It’s important to understand the difference between web applications and network firewalls.
- Network firewalls separate internal networks from the Internet.
- Web app firewalls monitor and block malicious or non-compliant web-based requests.
- Zero-trust networks protect you by assuming applications cannot be trusted.
Many of us are familiar with the concept of a network firewall as a protective device that separates our internal network from the Internet. But the concept of an applications firewall is perhaps less well known. One of the reasons is that unlike a network firewall, an application firewall isn’t a single entity. It actually encompasses multiple products and operates across a variety of application purposes.
These tools are certainly needed: according to Veracode’s State of Software Security report, 83% of the 85,000 applications it tested had at least one internal security flaw. Many had much more, as their research found a total of 10 million flaws, and 20% of all apps had at least one high severity flaw. And that is just the apps themselves: taking a look at the top web-based application exploits, there are things like SQL injection and cross-site scripting attacks that are still fairly common occurrences. According to one report, these vulnerabilities have increased rapidly in open source projects in the past year. Let’s explore that universe and give you some guidance about how you should protect your collection of business applications.
Different Firewall Tools
The first type of tool that you should deploy is the web applications firewall, like what Network Solution sells with its Sitelock offering. This is designed to monitor web-based requests and block those that are malicious or don’t comply with specific rules. In the abstract, it is very similar to how a network firewall works. It is designed to catch some of the exploits mentioned above, along with authorization abuses and ways to manipulate web servers in evil ways to penetrate your network. None of these attacks are new, and some date back to the early days of the Internet when Network Solutions was the sole domain provider.
However, the comparison with network firewalls breaks down quickly. Unlike a network, a web server doesn’t have any “hard edges,” for lack of a better term. One potential threat source is with products that come with embedded web servers such as network printers. You need a web application firewall to keep any printer-based attacks from further infecting the rest of your network.
Complicating matters further, these web app firewall functions can come as part of other web-based products, such as proxy servers, caching servers and web server load balancers. In addition, web apps are in a constant state of change which makes invasions harder to catch and prevent. And then when you add the fact that many web apps are home-grown and developed by non-IT staff, you can see that a web app firewall has to fill some pretty tall shoes.
A good place to start your evaluation is this OWASP paper that describes some of the best practices around these firewalls, such as creating an app priority list for your firewall and understanding the various roles and responsibilities of your security staff. Another great place to learn some of the basics of web application security is from Tanya Janca’s list on her blog.
A second class of tools that you will probably want to look at after your web app firewall are cloud access security brokers. They are used to monitor traffic among various cloud and on-premises applications and ensure that only authorized users have access to this data. One of the top ten OWASP exploits is broken access controls, and these tools can help prevent this.
Moving Towards Zero-Trust Methods
A third group of tools is aimed at preventing broken application authentication and session management. These range from simple password managers to more complex solutions such as single sign-on products. Both can generate complex passwords, employ multi-factor authentication methods, and also automatically deactivate users when they leave your company.
One potential solution is to examine what is called zero-trust methods. This means that rather than assume your apps can be trusted, you start off by stating that they can’t be, and everyone and everything has to properly authenticate each login and transaction. This avoids the situations where hackers have lived inside a corporate network for months undetected and were able to move through internal systems because they could elevate their access rights. And as companies make use of more cloud-based computing, this trust issue is only going to get worse.
The tenets of zero-trust methods include being able to segment your network into tiny pieces, to create risk-based multi-factor authentication that can continuously adapt on the fly to circumstances, and to create conditional access policies that can match these circumstances. While the term has been around for a decade, it has gained a lot of traction in the past few years and a group of industry experts have put together this working architecture draft document. There are a number of vendors who sell zero-trust products, such as Proofpoint, Palo Alto Networks and Pulse Secure.
While it is nice to have choices, as you can see, figuring out the right combination of tools and policies will take some effort. Contact Network Solutions for more information.