Elke (potentiële) koppeling tussen twee netwerken betekent een risico. Zoals MathFox en anderen schrijven, kan een firewall helpen om een deel van de risico's te mitigeren. Als die firewall bijv. NTP verkeer tussen de twee segmenten blokkeert, kunnen door een aanvaller aan B verzonden gemanipuleerde NTP pakketjes in principe geen systemen aan A bereiken.
Echter als de firewall onjuist is geconfigureerd (wat maar al te vaak gebeurt, bijv. als iets niet goed werkt worden vaak poorten opengezet die men daarna vergeet dicht te zetten, of de beheerder weet niet dat een applicatie niet meer gebruikt wordt, of de beheerder snapt niet hoe firewalls werken en heeft "allow all" als default policy laten staan -wellicht omdat hij een keer moest gaan rijden toen hij vergeten was bidirectioneel ssh verkeer toe te staan- of geheel niet aan IPv6 gedacht heeft), of als die firewall zelf kwetsbaarheden heeft die vanuit A getriggerd kunnen worden, of via A op onveilige wijze z'n updates krijgt, kan een aanvaller mogelijk misbruik maken van deze situatie.
In een "assume compromise" situatie is het verstandig om ook zoveel mogelijk soorten verkeer van B naar A te blokkeren en blauwe zwaailichten aan te zetten en sirenes te laten gillen als er pogingen worden gedaan om ongewenst netwerkverkeer die kant op te sturen.
En, actueel: als je bijv. ESXi hosts aan je management (V-) LAN hebt hangen (segment B), en een virtuele guest daarop gekoppeld is aan segment A (bijv. DMZ) dan zou ik, zodra VMware een patch uitbrengt voor een recente guest2host vulnerability (nog geen CVE bekend voor zover ik weet), deze maar snel installeren (en duimen dat
die patch wel in een keer goed is). Zie
https://www.theregister.com/2020/11/09/tianfu_cup/ en
https://blogs.vmware.com/security/2020/11/vmware-and-tianfu-cup-2020.html.