NSA Network Infrastructure Security Guidance [pdf] (opens in new tab)

I guess he meant to say that each product has its own attack surface, using n different products just make your attacking surfaces multiply by n. It would be true if you mix those at the same layer. Even if you deploy them in different layers, you still have n different types of devices to maintain instead of one. And it would provide little benefit if different lays of the network were not segregated correctly as the chance to breach the very first layer remains the same.

Plus the points you pointed out, there is not much point to deploy such strategy unless you have more than enough budget.

The scenario I had in mind is Firewall A and Firewall B are in series and they're different products from two vendors. Firewall B is found to contain a vulnerability triggered by a specially crafted IPv6 TCP packet (that firewall A is happy to pass to firewall B), giving the attacker a level of control over Firewall B that allows them to then access the centralised authentication/authorisation system that would have otherwise been off limits to the attacker. The attacker communicates with firewall B using the same accepted protocol that firewall A and firewall B are configured to allow the attacker to access. Firewall B communicates to the authentication/authorisation system using the accepted protocol for doing so. Nothing suspicious appears to be going on unless you look at the patterns of traffic (throughput, duration of connections, number of connections in interval, etc) particularly to the authentication/authorisation system.

I don't think in-band attacks on routers, switches, firewalls doing simple ACL checks are a risk worth spending much concern on because parsing IPv4/IPv6/TCP/UDP headers is not hard to securely implement. Riskier architecture would be intrusion detection systems that perform deep packet inspection in-band (e.g. not out-of-band via a beam splitter to a standalone IDS) where there is 1,000,000's of lines of potentially buggy code exposed to attackers.

I agree with your point too that a complex network is harder to secure because you need more skill and expertise spread across more people. In such a scenario, it is easier for human mistakes to occur because of the difficulty in communicating, and difficulty in seeing the broader implication of what may appear to be a simple configuration change.

As you increase the number of systems in series you increase the likelihood of failure. In this case failure is "there's an exploit." When you have A->B->C it's possible that exploiting B, the middle layer, is both possible by going through A but also allows you to pass traffic through C that lets you launch an attack or exfiltrate from the network.

In practice it may be different, but it seems like security theater to just put a bunch of firewalls in series.

Firewalls are good spoils, your payload can then monitor, exfiltrate, or meddle with traffic, or use it as a stepping stone to network infra/administrators.

In that example network, the Chinese, US, Russian, Israeli and other firewall vendors with their products in series could all have access to the network as each of them has implemented a backdoor that triggers on a hidden condition such as HMAC(secret_backdoor_key, CONCAT(ip.source_address, tcp.source_port, ip.destination_address, tcp.destination_port)) == tcp.sequence_number.

Obviously if such a scenario were to play out, a backdoor would be designed to look like a mistaken bug in the software (also making it very hard to detect) rather than the simple example.

Fault tolerant architectures such as N-modular redundancy[1] (typically used in the aerospace sector) may provide a more accurate architecture up front. Making protocols much more deterministic and only using nothing-up-my-sleeve numbers would be a good line of investigation.

[1] https://en.wikipedia.org/wiki/Triple_modular_redundancy

[2] https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number

When we are implementing this are there diminishing returns on the luck granted by the pfSense firewall?

If not, wouldn’t it be better to stack pfSense and rely on luck alone. This would also save us money as we could run them all on the same server in VMs.

Sincerely, your customer

> Many big companies have what is basically a MITM attack on SSL. They resign everything between you and the network endpoint using an enterprise certificate. It's still encrypted but at some point it's decrypted, inspected, and then re-encrypted. It's mostly seamless but sometimes you have to get a copy of the certificate to add it to things like pip.

Yes. And this is a good thing (in an enterprise environment) for a couple of reasons (a few others too, but these should make the point):

   Proxying connections is inherently more secure
   than packet filtering/stateful inspection;

   As was pointed out in another comment[0], most 
   traffic is encrypted these days.  Any traffic 
   traversing the enterprise network needs to be 
   visible (unencrypted) to network administrators.  

   This allows them to identify, investigate and, 
   potentially, block suspicious traffic.

Any large organization (or even smaller ones with the need and the resources) should be able to decrypt and read every packet traversing their internal network and the ingress/egress points to/from that network.

That requires ubiquitous use of proxies for all connections that have an external endpoint.

It's likely that some sensitive internal networks/servers/applications should do so as well.

While that's very intrusive, it's not your home network, nor is it (semi-)public wifi. It's the wholly owned property (I'm not addressing "cloud-based" resources here -- that's a different long discussion) of that organization.

As such, they have every right to read every packet on their network and every byte on their storage.

Which is why many organizations have "guest" networks which not only has no access to internal resources, but also only allows connections to external networks and bypasses all the proxies/firewalls as well.

This allows employees, contractors and others to maintain their privacy on their own devices without impacting the security of the internal network.

Of course, this requires device authentication at the network layer (e.g., 802.1x) to ensure that only authorized devices are permitted access to the internal network.

None of the above is particularly new or particularly controversial.

[0] https://news.ycombinator.com/item?id=30574794

I'm talking about op-sec. Network design is but a single aspect of that, and often doesn't feature at all. I mean this more in the sense described by Wikipedia¹, and not the likes of SecurityStudio²/Fortinet³ (first two search results).

¹ https://en.wikipedia.org/wiki/Operations_security ² https://securitystudio.com/operational-security/ ³ https://www.fortinet.com/resources/cyberglossary/operational...

The way it's usually implemented is two sides of a wall have a mesh in them, similar to chicken wire.

Jams all signals, doesn't require a beacon to be constantly transmitting.

There’s heaps of content in the NIST 800- series, which is all available online

Yes. I assume you're asking if they're publicly available, which is a no. Is not an easy world to penetrate, for good reason.

I highly doubt any of the content in this is ‘bad’ or misleading - most security people have a pretty good BS detector and it would spread pretty quickly in the community.

The worst thing might be a reference to an industry standard protocol, like IPSECv2, which is generally considered secure, but might be broken under certain conditions and only ever exploit under extreme circumstances (to avoid showing their hand).

> to make networks less safe

Could it be substituted by "to get into a network"? Then it could be argued that they need adversaries to establish reliance on a working network.

I too am all for sharing best practices. I just disagree with some of those practices. Using a mixed bag of a particular product from a variety of vendors sounds great from a management perspective. It seems obvious that one might catch something that another misses. Having a variety of security products watching a network is like how a variety of COVID vaccinations can be better than repeating the same vaccine each time. But more vendors means a greater variety of associated traffic. You end up poking a hole in one firewall so that someone can manage some other firewall. Your IDS sees, and gets used to seeing, all sorts of strange management traffic. Your engineers become complacent, opening up holes upon request by anyone with the correct phone number. There is something to be said for a single strong firewall system from a single vendor. Then you have a single reporting/monitoring system with no shirking of responsibility. That one wall is manned/watched/managed as everyone's first priority. One very tall wall rather than a series of shorter ones.

The practice I would promote, but which is rarely ever used outside of defense and/or the biggest companies, is having separate networks for the really important stuff. Why is client data is traveling along the same network as employees streaming netflix? Have one network for general office junk and another physically-distinct network for client data. Why is the office birthday party announcement landing in the same inbox as an email from a "client" requesting a wire transfer? If separating these means some employees have to run two email inboxes or have two computers at their desk, so be it. But doing that costs money. Subscribing to a 3rd or 4th firewall vendor is cheap.