I think of classical firewall-based security like a community with a common manned gate, and where the homes inside the community don’t have locks on their doors. Strong locks on strong doors is better if you ask me.
Traditional firewalls look for patterns in the packet header to determine what action to take on flows that match specified patterns. I'd equate this to the security guard at the gate allowing in folks based by how they look. If someone looks like a person who belongs to the community, then they're let in. In the same way, if a crafted packet header matches permit rules in the firewall, then it is allowed through.
One might say that’s where app-based firewalls come in. They go deeper than just the packet header to identify the application that is being transported. But how do these firewalls know what application a transport session belongs to? Well, they do pretty much the same thing — look for patterns within transport sessions that hopefully identify unique applications. Which means that with a little more effort, hackers can embed patterns in illegitimate sessions that fool the firewall.
I suppose there are even more sophisticated schemes to distinguish legitimate flows from illegitimate ones that may work reasonably for well-known apps. Problem is the application you wrote (or changed) last week is not "well-known", so you’re back to the 5-tuple.
This is among the problems with man-in-the-middle security -- they're just not good enough to keep out the most skilled intruder for long. Break past the front gate and all the front doors are wide open. The dollars you expend for this kind of security isn’t limited to the cost of the security contraption. It also includes the limitations this security model imposes on application cost, velocity, scale and richness, and the amount of wasted capacity it leaves in your high-speed network fabric. Clos? Why bother.
One might say that server-based micro-segmentation is the answer to this dilemma. But what significant difference does it make if we clone the security guard at the gate and put one in front of each door? The same pattern matching security means the same outcomes. Am I missing something?
I'm sure there are even more advanced firewalls, but that surely bring with them either significant operational inefficiencies or the risks of collateral damage (like shutting down legitimate apps). I'm not sure the more advanced companies use them.
In my humble opinion, “zero trust” means that application endpoints must never trust anything in the middle to protect them from being compromised. Which means that each endpoint application container must know which clients are entitled to communicate with it, and allow only those clients to connect if they can present credentials that can be used to prove their true identity and integrity. Obviously a framework that facilitates this model is important. Some implementations of this type of security include Istio, Cilium, Nanosec and Aporeto, although not necessarily SPIFFE based.
Where backend applications universally adopt this security model, in-the-middle firewalls are not needed to ensure security and compliance in backend communication. Drop malware into the DC and it might as well be outside the gate. It doesn’t have keys to any of the doors, i.e. the credentials to communicate with secured applications. Firewalls can now focus on keeping the detritus out at the perimeter — D/DoS, antivirus, advanced threats, and the like, which don’t involve the management of thousands of marginally effective match-action rules, and all the trade-offs that come with blunt-force security.
Traditional firewalls look for patterns in the packet header to determine what action to take on flows that match specified patterns. I'd equate this to the security guard at the gate allowing in folks based by how they look. If someone looks like a person who belongs to the community, then they're let in. In the same way, if a crafted packet header matches permit rules in the firewall, then it is allowed through.
One might say that’s where app-based firewalls come in. They go deeper than just the packet header to identify the application that is being transported. But how do these firewalls know what application a transport session belongs to? Well, they do pretty much the same thing — look for patterns within transport sessions that hopefully identify unique applications. Which means that with a little more effort, hackers can embed patterns in illegitimate sessions that fool the firewall.
I suppose there are even more sophisticated schemes to distinguish legitimate flows from illegitimate ones that may work reasonably for well-known apps. Problem is the application you wrote (or changed) last week is not "well-known", so you’re back to the 5-tuple.
This is among the problems with man-in-the-middle security -- they're just not good enough to keep out the most skilled intruder for long. Break past the front gate and all the front doors are wide open. The dollars you expend for this kind of security isn’t limited to the cost of the security contraption. It also includes the limitations this security model imposes on application cost, velocity, scale and richness, and the amount of wasted capacity it leaves in your high-speed network fabric. Clos? Why bother.
One might say that server-based micro-segmentation is the answer to this dilemma. But what significant difference does it make if we clone the security guard at the gate and put one in front of each door? The same pattern matching security means the same outcomes. Am I missing something?
I'm sure there are even more advanced firewalls, but that surely bring with them either significant operational inefficiencies or the risks of collateral damage (like shutting down legitimate apps). I'm not sure the more advanced companies use them.
In my humble opinion, “zero trust” means that application endpoints must never trust anything in the middle to protect them from being compromised. Which means that each endpoint application container must know which clients are entitled to communicate with it, and allow only those clients to connect if they can present credentials that can be used to prove their true identity and integrity. Obviously a framework that facilitates this model is important. Some implementations of this type of security include Istio, Cilium, Nanosec and Aporeto, although not necessarily SPIFFE based.
Where backend applications universally adopt this security model, in-the-middle firewalls are not needed to ensure security and compliance in backend communication. Drop malware into the DC and it might as well be outside the gate. It doesn’t have keys to any of the doors, i.e. the credentials to communicate with secured applications. Firewalls can now focus on keeping the detritus out at the perimeter — D/DoS, antivirus, advanced threats, and the like, which don’t involve the management of thousands of marginally effective match-action rules, and all the trade-offs that come with blunt-force security.
No comments:
Post a Comment