Saturday, September 26, 2020

Network Security Ops wants a single pane of glass for firewalls, engineering wants to separate cloud and on-prem.

Simplest way I can say. We have about 50 Fortigate 3400Es in our environment across 3 company-owned major datacenters, as of now they are managed via a Fortimanager, we rely heavily on change control, no undocumented changes, all pushes are at a documented time with validation of all changes and rules. Lately our org is expanding to Azure and we're standing up several Fortigate VMs, some that scale, some that don't but ultimately that has lead us to currently 3 Fortimanagers and a 4th one in the near future. They are saying they will 'eventually' consolidate down to one FMG in cloud and maintain the one fmg for on-prem. Currently we're running on newer code in the cloud and the on-prem FMG can't manage the newer version ones(but we just ran into a code bug for VPN which will require the FMG to upgrade to a newer version that CAN manage the cloud firewalls)

One of the hardware engineers is vehemently against having one FMG citing these reasons:

  1. dependency - don't want requirements in either on-prem/cloud to dictate code restrictions on the other - this is a valid concern, probably the only one, but a minor one
  2. features - we do not want to deploy. potential features or codes that oculd be leverage and unique for either environment - he listed this as a reason which i think actually goes against his convictions
  3. risk - risk of human error, performance, connectivity - which my counter point is a single pane of glass reduces errors, performance is negligible since if we lose access to cloud we lose access to the cloud FMG anyway, we're getting a 100 gig expressroute redundant circuit set up, i'm very skeptical there will ever be a major connectivity issue. performance is the only valid concern but barely.
  4. elasticity - they state that on-prem FMG would not be useful for elastic firewalls yet the FMG code is the same regardless if it's hardware or not... fluff reason in my opinion.
  5. vdoms/adoms - on-prem we use ADOMs to separate VDOMs based on environment (prod/nonprod) we don't do that in azure - stupid reason, makes no sense. salty response but i don't like dumb reasons.
  6. limitations - we face limitations with objects, latency, complexity, duplication, connecting cloud to on-prem increases these complications and limitations - back to risk, stupid response, more fluff work, not sure what's complex about deciding management in one datacenter or another.
  7. flexibility - we can adapt to increasing demands changes, needs in the cloud quicker with having a separate environment - this in no way affects whichever method you're using, stupid response.
  8. deployment - deploying cloud firewalls has a native code version that may not align with on-prem, we do not want to spin up a firewall in cloud that isn't compatible with fortimanager - valid but in a company environment where we strictly control changes and assess risk on every minute detail, we wouldn't just 'spin' up new equipment without research and preparation
  9. upgrades/downgrades - per previous conversations, when possible, we should avoid upgrading or downgrading firewall code to be in align with on-prem we should leverage what is provided in cloud - references reason 1 just in a different way.

from the ops perspective, there's a growing demand with object control, group control, we're leveraging global objects and policies which will be spanning datacenters and into the cloud for akamai purposes. Addtionally, why would be want to support our central management of these firewalls to be hosted elsewhere when we already have the infrastructure and opportunity to host it in a more secure environment, one that we control not to mention a reduction in cost... it doesn't make sense to me.

to top all this off, they say fortinet, the vendor, has given their blessing to separate management, which in my opinion is an extremely obvious case where a vendor is going to recommend any opportunity that utilizes more revenue for them.. so on a partial level we shouldn't trust their recommendation this.

I have previously worked in a major ISP that acted as an MSP for business customers using fortigate equipment, we had multi-tenant devices and used vm fortimanagers as well physical vms and neither one had a problem managing physical or vm devices. I think the engineering team has a weak leg to stand on taking this stance, but i am willing to listen to reason if there are real legitimate concerns, yet i don't really see any. i'd love to hear from other experiences.



No comments:

Post a Comment