Conquering Layer 8 and 9 When Implementing Layer 7 Protection

After 10 years of deploying web application firewall (WAF) solutions for small, large and outlandish company infrastructures, I have learned what it really takes to get the job done. It's not protecting 1,000 applications or having the ability to place a check mark on a compliance document. 

If that is not the goal, then what is? In my world, it is creating a 'supportable and repeatable process' to deploy security policies. 

I am the layer 3 firewall king; a layer 7 firewall will be just as easy.

It is easy to create a security policy and start that learning process. It is also easy to place that policy in blocking mode and possibly break some functions, but hey, it's in blocking. You can also easily turn off blocking to fix the mitigation of a legitimate request — that will fix it. If it is that easy, then create 1,000 exact policies or use that same policy for 1,000 applications. I will bet all 1,000 applications are the same encoding with the same functionality. 

Yes, that will put a stamp of approval on this project. No, none of this will work and never has it been the case where you can just set it and forget it.

Layer 7 protection is unique and catered to what application you are trying to protect. Even more unique is the layer 8 aspect you run into when deploying a layer 7 security policy.

The OSI model is layer 1 through 7, right?

Layer 8 is defined as a term used to refer to "user" or "political" layer on top of the 7-layer OSI model of computer networking according to Wikipedia. For us in the industry, it is what makes layer 7 protection that much harder to deploy. It is not that users are trying to make the process harder or political aspects are hindering the project, it is just the way it is. 

When you are going to place a security layer on top of someone's or some team's application, they can get a bit defensive or concerned as to how that will change their daily routine. 

"Do we need to change our SDLC?" 

"Will this cause issues for the application and our users?" 

These are both good questions, and they need to be addressed.

Layer 9 is defined as the "organization" layer above the layer 8 user. How organizations are organized or not organized can determine the success or failure of deploying a layer 7 firewall. If your goal is to create that supportable, repeatable process, you need to ensure you know your organization prior to deploying your firewall.

Here is a WAF, get it done…

I did not know that layer 8 and 9 existed until I was handed a WAF back in the 2011 or so timeframe and asked to get it implemented into a large financial institution's network. As I remember the quote it went: "here is a F5 ASM, work with the application teams to block OWASP Top 10." Huh?

Back then WAFs were not as common as they are today but my skill set seemed to match up with what was needed to work with the technology. I was strong with applications and also understood networking, plus had experience with F5. The thinking was to use our normal processes to build the devices in the test environment, test, move to production, test and call it a day. This sounded great, but once we started the process it fell apart really fast. What the heck was different in this case? Why was it taking weeks to make progress with this technology?

After a few rounds of attempting to create, adjust and place violations into blocking mode it became apparent that this is not just a security device, it was a juggernaut causing havoc in numerous silos in the company and ruffling many feathers in the management ranks, but why? A layer 3 firewall doesn't cause this much pain, why would a layer 7 firewall?

When working with layer 7, you are touching all layers of the OSI model which from a technical perspective is not that difficult, but you are now also working with multiple teams in your organization. This is not to say that you do not work with them all when implementing a layer 3 firewall, but at layer 7 you need to know a lot more information about what you are securing in order to implement the technology and not impact the applications — or more importantly the money that those applications bring in. 

Gathering which source IPs, destination IPs and ports are needed for an application can be done via an email or form. Gathering URLs, parameters, file types, sensitive parameters, server OS information, methods, allowed redirect URLs and many other application specific items can take a lot of time.

Given the demands of this technology, I needed to take a step back and look at this from the 30,000-foot view.

Which teams know this information?

Who owns the applications?

Who tests the applications?

Who decides which violations are needed to be enabled?

Who supports these devices from a network perspective? What about from a security perspective?

The above questions needed to be asked prior to creating a security policy for any applications. This is where layer 8 and 9 came into play.

Time to try and herd those cats.

To address the questions from 30,000 feet, you need to create a proper communication plan. Most companies have silos that restrict the communication between network, app teams, security and other necessary teams to understand what is needed to implement a layer 7 firewall. 

This communication path must be documented and used prior to engaging each application team to ensure you are creating a supportable, repeatable model. This will allow administrators to understand why you are creating policies in a certain fashion and then also allow them to support the policies in case there were issues. If you have multiple admins creating different policies or not communicating the same model or mission, it will lead to chaos and become unsupportable quickly.

Here's an example organization chart for layer 7 security devices:

Security devices can be scary for IT professionals as many don't want the responsibility of being the first line of defense for the company or be the reason why the company is on the cover of a magazine because of a security breach. Developers are not fans of WAFs, as they expose their code to the security teams as well as show any defects that have never been taken care of, if unknown. They are a necessary evil which is why you need to have a plan to implement these types of devices.

If your company does not have this organizational structure in place prior to turning on your new L7 firewall, stop. As IT professionals, our first instinct is to rack it, power it up and start to build it. Again, stop. Look at what is needed to support this technology, what teams need to be involved and what communication needs to happen, then ensure you can create a supportable, repeatable process. If not, you are going to waste a lot of time and effort just to end up right back at this starting point, layer 8.

WWT has the experience to help you deploy layer 7 security devices from a technical perspective, as well as helping with the layer 8 unknown. Make sure to follow our Network Security focus area to stay up to date with this topic and more.