Ik ken geen bedrijf dat dit zo geïmplementeerd heeft.

Het kan wel zijn dat voor je een Internet facing firewall een andere leverancier hebt, dan je interne netwerk firewalls. Maar om deze zomaar even om te zetten, is niet "even". Firewalls kunnen intern anders werken. Daarnaast met 2 type firewalls, moet je deze insync houden, wat fout gevoelig en je moet voldoende kennis hebben, van beide firewalls/leveranciers.

Feitelijk een HA-cluster van twee verschillende ngFW's van verschillende vendoren waarbij je bij een geconstateerde kwetsbaarheid tijdelijk op een been gaat draaien?

Veel succes met twee totaal verschillende ngFW's zo configureren dat hun gedrag identiek is zou ik zeggen!

Als je dan twee vendoren wil gebruiken om security risico's te mitigeren, zou ik eerder voor het zwiterse kaas model gaan, waarbij je ze juist achter elkaar plaatst.

Maar beter nog is je gewoon op 1 product toespitsen dat je goed kent. De grootste security problemen zijn meestal niet een kwetsbaarheid in een appliance, maar de menselijke factor. Dus die aanvalsvector wil je beperken, en 1 product gebruiken dat je goed kent lijkt mij op dat gebied beter dan er een rotzooitje van maken met twee producten.

Nou nee, daar ben in IN PRODUCTIE totaal niet mee bekend. Niet vanuit het verzonnen concept dat je dat doet als een soort van dubbele laag security.
Het verhaal zoemt alleen maar rond op fora .

Vanuit die theorie zou je de devices in serie moeten zetten . (mensen 'capt'n , the outer shield has been penetrated by the skittle attack, but the inner shield is holding because it has the mass-phase-change composite' . Nee, zo werkt het niet).

Verschillende vendoren in een nauw gekoppelde HA setup werkt gewoon niet .

Bedrijven kunnen wel degelijk een dual-vendor policy hebben . Dat is meer zakelijk gericht - beide partijen weten dat bij een te dure offerte de ander de bestelling krijgt. Bij leverproblemen, of een tijdelijke achterstand in modellen wordt wat meer van "de ander" gekocht.
Ook goed voor de IT organisatie om niet vast te roesten op één vendor/platform.
HP en Dell laptops/servers, of zo iets. Sun en HP workstations, ooit eens.

De east coast firewall cluster Fortinet en de West Coast Juniper zou best kunnen - maar als je één acuut wilt uitzetten heb je nog steeds een erg grote impact. En vaker is zo'n situatie gewoon historisch gegroeit (tijd van implementatie waarin vender A de beste keuze was, en later platform new van vendor B beter ) en geen centraal design principe.

Zoals gezegd - HA/standby vereist heel erg dezelfde platformen, meestal tot en met software versie toe.
Een plek met twee parallele clusters (evt cold standby) puur vanwege security om te kunnen omschakelen heb ik ook in enterprises met erg ruime budgetten niet gezien.

Voor de thuis hobbyist , op een semi-vergelijkbaar concept : bouw eens iets met een database eronder, maak die database high-available door Postgres en Mysql te koppelen. Ontdek maar waarom twee Postgres servers HA koppelen, of twee Mysql servers HA koppelen wel doenbaar is, en een van elk niet gaat , of een gruwelijk wangedrocht wordt.
Je hebt dan hetzelfde probleem als twee HA-firewalls koppelen.

Op z'n best mag je hopen dat iets simpels als een netwerk gateway (hsrp/vrrp) wel dual-vendor interoperable is. Zelfs dan is het goed lezen of ze prioriteiten hetzelfde doen.



Je neemt HA voor de hardware redundancy, en je gaat er gewoon vanuit dat je zero-days/DoS risico's kunt mitigeren, eventueel ten koste van functionaliteit als ze zich voordoen.

Je kunt ook observeren in alle berichten over firewalls met problemen dat er -ook bij erg grote partijen van wie je dan zo'n hype rveilig-altijd HA concept verwacht werd - impact was als ze toevallig op een platform met problemen zaten.

Daarom is het cruciaal om niet alleen te kijken naar de diversiteit van de leveranciers, maar ook naar de onderliggende architectuur en de componenten die zij gebruiken. Een gedegen risicoanalyse en monitoring zijn essentieel om deze risico's te mitigeren."

Net zoals de reageerders hierboven heb ik nog nooit een praktijkoplossing gezien waarbij je een cluster van producten neerzet van verschillende leveranciers. De complexiteit, kosten, beheerslast en problemen die je hiermee introduceert maken meer kapot dan je denkt op te lossen wanneer je last hebt van een zero-day.

Het concept dat je beschrijft is vanuit een resiliency optiek wel interessant. Het verhaal van de Ariane 5 is bij sommigen wellicht bekend. Die explodeerde doordat zowel de primaire als de backup SRI hetzelfde probleem in de code had (veroorzaakt door een overflow). Gevolg: eerst begaf het primaire component het, en door het gebrek aan diversiteit ook de backup. Einde Ariane 5. Zie de informatie hierover op de website van Ian Sommerville, die de casus beschrijft in zijn Software Engineering boek (https://software-engineering-book.com/web/ariane/), alsmede de video voor wat vuurwerk (https://www.youtube.com/watch?v=PK_yguLapgA).

Als je in de praktijk system resiliency na wilt streven, dan kun je beter andere methoden hanteren dan de door jou voorgestelde methode van leverancierdiversiteit. Een serie met goede blog posts hierover is geschreven door Donald Firesmith, voormalig Software Engineering Institute medewerker. In zijn vijfde post geeft hij een stapel resilience technieken, waaronder de door jou voorgestelde redundancy en implementation diversity. Het is een aardige leeskluif, maar als je alle 7 blogposts hebt gelezen, dan heb je een solide basis om te bepalen hoe jouw "probleem" beter aangevlogen kan worden.

Voor de blog posts, zie de volgende URL's:

Deel 1: https://insights.sei.cmu.edu/blog/system-resilience-what-exactly-is-it/
Deel 2: https://insights.sei.cmu.edu/blog/system-resilience-part-2-how-system-resilience-relates-to-other-quality-attributes/
Deel 3: https://insights.sei.cmu.edu/blog/system-resilience-part-3-engineering-system-resilience-requirements/
Deel 4: https://insights.sei.cmu.edu/blog/system-resilience-part-4-classifying-system-resilience-techniques/
Deel 5: https://insights.sei.cmu.edu/blog/system-resilience-part-5-commonly-used-system-resilience-techniques/
Deel 6: https://insights.sei.cmu.edu/blog/system-resilience-part-6-verification-and-validation/
Deel 7: https://insights.sei.cmu.edu/blog/system-resilience-part-7-16-guiding-principles-for-system-resilience/

Dat is niet helemaal juist als samenvatting - en daarmee de conclusie ook niet.
Het was , in zekere zin, een meta-bug, niet "gewoon" een software bug.

De software (voor Ariane 4) was perfect geschreven voor de design requirements - van Ariane 4.
Waaronder gegarandeerde maximale input waarden (van versnelling) van sommige sensoren.

Wat niet gerealiseerd was - die parameters konden bij Ariane 5 _wel_ een grotere waarde krijgen .
Waarop de software ongeschikt reageerde .
Je kunt niet blindelings stellen dat een diverse implementatie tegen dezelfde foute specificatie "beter" zou reageren.
(halt system kan ook een design keuze zijn als reactie op een 'impossible input' ).

Je zou datzelfde kunnen stellen wanneer standaarden sommige situaties niet specificeren ('implementation defined' , "undefined behaviour" ) . Andere software in dezelfde omstandigheden heeft dan mogelijk ander gedrag, maar niet noodzakelijkerwijs "beter" of "meer correct" .

Het zijn bugs - maar in specificatie / design, niet helemaal hetzelfde als 'gewoon software bugs' in de zin van 'programmeur maakte een fout' .

Dual vendor strategie wordt (werd) sequentieel gebruikt, niet parallel. Dus bijvoorbeeld eerste een (externe) fortigate firewall en daar achter een (interne) checkpoint firewall. Een "bug" in een van de firewalls levert niet meteen toegang tot het interne netwerk. Dit geld ook voor andere oplossingen. Antivirus/malware vendor op de mailserver een andere dan op de endpoints. SSH via een bastion host met daarna een ander vendor/software stack), etc. Je komt het steeds minder tegen. Er wordt nu beter gemonitord en sneller gereageerd. Voor zero days worden er verschillende oplossingen gebruikt bijvoorbeeld, dedicated firewall op servers (iptables), zero trust, etc.