from Hacker News

NSA Network Infrastructure Security Guidance [pdf]

by slacka on 3/6/22, 12:48 AM with 55 comments

• by FourthProtocol on 3/6/22, 7:37 AM

  I have some experience here, not with the NSA though. BYOD is forbidden, and checked when you enter the building. There is only wired hardware - and wireless is, well, jammed. Any software introduced into such networks is vetted before introduction/deployment. It takes time. 3rd party apps don't auto update - Microsoft for example provide updates that can be vetted before being allowed onto the network.

  And this is only some bleedingly obvious stuff...

  The document does not describe SECRET or TOP SECRET environments. Not even RESTRICTED. R, S and TS policies are themselves marked with protective markings, which this PDF lacks.

  Governments have a lower level of protection called PROTECTED or similar that is closer to what the document describes, but even that would be protectively marked...

  Looks to me like NSA is sharing some of their lesser sensitive stuff to possibly help their vendors, businesses partners and public at large. Kind of like "we recommend Joe Public do it like so..."

• by dhx on 3/6/22, 3:33 AM

  Use of firewalls in series from multiple vendors sounds like a good idea in theory but in practice, does it not make it easier for an attacker to exploit the network? Instead of the attacker having to find a vulnerability in a single product, they can instead find a vulnerability in one of multiple products (a much easier task). Given that every network device communicates with a central authentication/authorisation system, a central logging system and likely central patching, configuration deployment, etc systems, all it takes is to find a vulnerability in one of multiple firewall products, then find a vulnerability in one of the central systems used to mange the network.

  I'm also perplexed why there is mention of "traffic inspector" and "full-packet capture device" given that almost all traffic traversing a network nowadays is encrypted. Perhaps more useful today would be creating a good understanding of the normal traffic flows so that alarms can be configured for abnormal traffic. For example, perhaps no more than 100 requests to an authentication server occur per device per day. Or patches for a system are no more than 1GB so seeing 1.1GB or more transferred across the management network per day per device would be abnormal.

• by javajosh on 3/6/22, 5:00 AM

  What, no threat model? I'm really not sure who this is for. If you're actually in charge of network and/or security architecture most of this is too simplistic. But if you're a newbie it leaves out the the most important context (particularly, the threat model) that drives the entire process of securing something. And personally, I'm just not comfortable doing things unless I know why I'm doing it, and that's what the threat model provides.

• by rapjr9 on 3/6/22, 5:36 AM

  What do you all see as missing from this document? How about the security of apps and of 3rd party update services? Every app that has internet access is a potential vulnerability for the whole network, a direct route to the inside. And we've also seen recently that 3rd party software update services can compromise everything. Are those not considered part of "Network Infrastructure Security"? If you're talking about defense in depth you can't limit the discussion to just the wired network hardware itself because there are all sorts of other things that can compromise the network (insider attacks, BYOD, compromised hardware, phishing, blackmail). You could follow every single step in this document perfectly and your network may still be easily compromised. There's no mention of wireless networks either. Your network could be compromised via an open Bluetooth interface. This also seems like a very Cisco oriented document.

• by jabl on 3/6/22, 9:06 AM

  Slightly related, is there any analytical writing on the human side of security? How to build organizations that are resistant to intrusion in various forms?

  From reading books and watching movies as well as applying a bit of common sense, organizations like spy agencies or terrorist networks with more or less independently operating cells work with a strict least-privilege type model such that a mole in one part of the organization doesn't compromise the organization as a whole. And, I'd guess, at least in more formalized organizations, strict logging on who does what etc.

  All this obviously adds a lot of overhead and friction in communications, which, say, a business operating in a competitive environment can ill afford. I'm quite sure there's no "magic pill", but rather a bunch of choices with tradeoffs (like security vs. ease of cross-team communication I touched on above).

• by sandworm101 on 3/6/22, 4:19 AM

  Cool. Defense in depth. But how many vendors/products are now on the table? What will always matter is the most external firewall because once inside that line each subsiquent internal firewall will have a harder time viewing good traffic from bad. And the most inner firewalls between devices inside the home network will have so many holes punched in them to barely be useful. Defense in depth isnt about having multiple layers that repeat the same protections. Defense in depth is about having other layers of non-firewall products to catch the stuff the firewalls miss. If your outside wall is 8' adding more and more 8' walls behind the first does nothing if the army has 9' ladders. You need something different than another wall.

• by based2 on 3/6/22, 10:21 AM

  ?

  - No full static addresses requirement

  - No double WAF vendors requirements